Agriculture
Workflows > Usecase > Agriculture
Use case: The Go client operate in the agriculture industry, and have activated the agriculture settings and functionality in Go.
The purpose of this article is to provide an overall description of how the agriculture functionality work in Go, and how an agriculture client will affect the behavour of various api endpoints.
Go agriculture settings
A client may operate in the agriculture industry and use Go with ordinary settings, but since the end of 2023, the system support dedicated agriculture functionality. When a client activate the agriculture functionality, this have implications for the api and how to approach various workflows, whether it is reporting data from the client or sending data to the client.
Chart of accounts & agriculture departments
Once activated, the first event will be that the standard NGAAP chart of accounts is replaced by the NIBIO agriculture accounts, requiring 6 digit accounts. In Go this is implemented by requiring a 2 digit agriculture department in combination with the ordinary account number. The regular account numbers will no longer be unique, but must be viewed in relation to the agriculture department.
The old, regular accounts will be set as inactive, and new additions of the accounts will be added with various agriculture departmets. For instance, the chart of sales accounts might look like this in the user interface after activating the agriculture settings:
In the screenshot, we can observe 5 instances with the account number 3000. The ordinary 3000 account is inactive, and 4 standardised instances of account 3000 is added with a corresponding aggriculture department differentiating them. Note that all 5 of the 3000 accounts will have different identifiers and can be differentiated by id as well, in api operations.
The purpose of the NIBIO chart of accounts and our implementation of it in Go, is that an agriculture client have to differentiate their reporting on the varous activities they operatate in. The agriculture departments are a fixed set of codes used for this separation, not to be mixed with the department dimension/department entities otherwise available in Go. The following agriculture departments are in use on an agriculture client:
None - Unspecified
Finance (10) - Financial (Norsk: Finans)
Farming (20) - Farming (Norsk: Jordbruk)
Forestry (30) - Forestry (Norsk: Skogbruk)
OtherIndustries (60) - Other industries (Norsk: Andre næringer)
Private (90) - Private (Norsk: Privat)
Upon activation of the agriculture settings, a default agriculture department is set for the client. This will be the default agriculutre department suggested on transactions posted in the user interface, unless otherwise set or overridden in the chart of account settings.
All account transactions should be posted with the correct combination of account number and agriculture account, in order for the client to correctly differentiate the reporting.
Quantity fields
Activating agriculture, will activate a second quantity field that can be used on account transactions. The purpose of having two quantity fields, is to enable reporting of two different units simultanously - for instance the number of cows delivered + the number of kilograms delivered:
The unit used on the quantity fields on a transaction, are defined in the chart of accounts and settings of each account. From the example in the screenshot above, the account 3041.20 is defined with unit1: each and unit2: kg, in order to interpret the unit of measure of the quantity fields used on the transaction.
Agriculture detail fields & integration with Landbrukets Dataflyt
Once activated, the system adds the ability to supplement voucher's on the client with detailed agriculture information, in the journal entry view in Go. In the user interface, these details will be available by pressing the new tractor icon on voucher lines, as seen in the screenshot.
The information in these fields are used in dedicated reports in Go. If the client set up the supported integration with Landbrukets Dataflyt, the detail fields will be automatically set when the client receives settlements and invoices via Landbrukets Dataflyt.
The agriculture details is not currently exposed in the api, with one exception included at the end of this article.
Effect on the API-endpoints
Information on whether the client use the agriculture or not, and if so what the standard agriculutre department is, can be retreived from the Organization Settings endpoint .
For agriculture clients, the chart of accounts must be viewed light of the combination of account number and agriculture department, when operating with the general ledger account endpoints. The accounts can also be differentiated by their identifiers once the id's are mapped.
Customers and customer ledger /Suppliers and supplier ledger:
The standard approach is to have one ledger per customer/supplier (regular setting)
The alternative approach, if the client choose so, is to have one ledger per customer/supplier per agriculture department. This means there will be up to 3 "duplicates" of the same customers/suppliers residing within up to 3 different subledger series.
When retrieving the trial balances , the elements must be viewed light of the combination of account number and agriculture department to differentiate, and/or the identifiers. Depending on the usecase and reporting purpose, the trial balances can be used "as is" or one might be aggregated after retrieval to summarize of accounts with the same account number.
On account transactions retrieved, the transactions may include agriculture department and quantity2 properties
In any endpoint sending data to Go, with references to a general ledger account, id's should be used to reference the correct general ledger account. For some endpoints, the POST dto's do support referencing the account number, but if used, a reference to the agrulture department must be provided as well. The system validates that the correct combination of account number and agriculture department exist in the chart of account. We reiterate that id's work better for referencing objects.
For special use cases with the journal entry voucher endpoints, the agriculture details may be relevant to include. These endpoints are the only ones that will include the agriculture detail.