Summary
The Prodoc RFP module is used to process RFP/REX submissions via EXDOC/NEXDOC. This separation allows for a 1:1 match between Prodoc data and the data on file at Dept. Agriculture (DAFF), and specifically allows updating Prodod data based on changes from DAFF without interfering with commercial documents. Use of the module is explained below.
Creating a new blank RFP
From the Prodoc Home screen → Create New Work panel, a user can select to Create a new RFP provided the option has been enabled in Prodoc Admin. When switching to RFP a new option is presented allowing the user to select the Commodity for the RFP, which will default to the system default. The RFP reference, Customer and Commodity Type must all be specified.
Using this option will create a new ‘blank’ RFP that only has the commodity and details for the customer completed.
Creating an RFP from a Shipment
On an RFP enabled Prodoc system an additional button will be shown in Shipments:
Clicking this button switches to the RFP from the Shipment, and an equivalent button within the RFP switches back to the Shipment (both stay open when switching).
When clicking the button for the first time in a Shipment you will be prompted to create a new RFP.
Upon clicking Yes, Prodoc will use the Shipment → RFP interface to create a new RFP. Configuration of the interface can vary to suit the available data at the Shipment level.
Navigating an RFP
An RFP operates in the same way as a Shipment, with the same four screens and a button to switch focus back to the Shipment.
Dashboard
The Dashboard operates in the same was as on a Shipment, having its own Notes, Tasks and History. The Tasks are configured separately for RFP/Shipment and so can be configured to suit an RFP (instead of showing all tasks that are required for a Shipment).
Details
The Details screen differs from that in a Shipment, instead showing the available data entry fields for the currently selected commodity.
Some fields will appear/disappear based on the selected commodity - for example Catching Zones are visible for Fish, whilst Wool exports allow for up to 5 load ports.
Most of the requirements are fairly clear (e.g. Ports, Departure Date). Some of the less self-explanatory fields are explained below:
Status | Automatically updated after submissions or notifications change it |
RFP No | This shows the RFP/REX number received from DAFF |
EDN | This shows the EDN received from AU Customs |
Certificate Print Indicator | This tells NEXDOC what to do when a certificate is ready. If set to Automatic the certificate will be generated, set to Manual the REX will stay at CTRD until the print indicator is changed to Automatic, or if set to Not Required then no certificate will be generated. |
Certificate Required Location | This tells NEXDOC who will be printing the certificate when it is not a DAFF office. |
Print Region | This tells NEXDOC which DAFF office is printing the certificate if no location is specified. |
Self Authorised | AEPI registered users should tick this if they wish to authorise their own REX. |
Forward details | |
Supporting Documents | Any documents required to be submitted as part of the REX can be added here, and their purpose specified. |
Note that the EU Requirements panel currently appears for all RFPs, but is only required for consignments entering or transiting the EU, and not all elements will be needed each time (for example it’s unlikely that both transit and destination details would be required).
It is assumed that most customers requiring REX will be familiar with the data entry fields. They have been named to align with the NEXDOC naming conventions where possible.
Products
NEXDOC uses the standard Products screen but with a Product / Container profile (or Products only for non-Container). This is because the NEXDOC message works in this way, with containers listed below each line item. This may lead to the same container being listed against multiple products, which is fine.
No quantity information is recorded against container lines, so it’s purely Container and Seal numbers.
An addition for the RFP module is that sub-product information is stored, with a single product line able to have multiple processes, treatments, etc. These sub-product buttons are added automatically based on the selected commodity e.g. Fish Harvest Areas are not available for Wool.
Clicking the Edit button on one of these items opens up a separate edit window with appropriate fields:
Some of the RFP-specific data elements are explained below. The four items marked in blue are the key fields identifying the product and were previously combined into a single code in EXDOC.
Preservation Type | How is the product preserved? |
Product Type | What is the product? |
Pack Type | How is the product packaged? |
Supplementary Code | Optional additional classification (e.g. Wild Origin) |
Product Category | Single code that indicates product type and cut |
AHECC | AU Customs Tariff Code. Required when requesting EDN |
Source State | AU State where the product is from. Required when requesting EDN |
Salting Date | Used for Skins/Hides |
Fish Water | Used for Fish to indicate fresh/salt water |
Catch Start/End Date | Used for Fish to record catching dates |
HC/Extra Template | This shows which health certificate template will be used. Extra template can be used when an additional certificate is required (such as Dioxin certificate for Dairy). Note that if no certificate is specified when lodging then NEXDOC will apply the default for the country/commodity combination. |
HC/Extra Endorsement | Additional certificate endorsements can be added here based on the Micor case used. They take the form of a number. |
Manufacturer | Used for some commodities. This uses a lookup to process plants in Prodoc. |
Related Permit details |
|
Processes | Captures the various processes a product has been through, where the process occurred and when. Example slaughter, processing, freezing. |
Free Text Establishments | Used for Fish, another process type box to indicate additional process types but specifying the establishment by name rather than code. Example aquaculture, catching. |
Harvest Areas | Used for Fish to specify where the fish/seafood was harvested and additional details about offshore dates and depuration. |
Treatments | Used for Dairy to specify information about treatments applied to the product. |
Forms
All submissions to NEXDOC are sent from the Forms screen using EDI messages.
NEXDOC responds to message almost immediately, and the results are shown in History. All NEXDOC messages are viewable in the Prodoc Support application.
Unlike other EDIs there are no panels on the right of the screen as the whole module is dedicated to storing data for these forms.
Each of the available EDI messages servers a different function described below:
REX VALIDATE | Sends current RFP data to NEXDOC, which will either reply with a list of errors/warnings or reply to confirm no errors are found. Can be used to check that the REX will be accepted prior to sending a lodge/order. No record is retained at the DAFF end and no REX number is allocated. |
REX ORDER | This is essentially a ‘draft' REX, which is often used to get a REX number and can also be used to obtain initial customs clearance (i.e. get an EDN) whilst the exact shipment details are not yet known. An Order will not progress to any other status and only be lodging the REX will it progress through the various stages to completion. Changes to an Order are made by sending a new Order message, which will replace the REX details entirely. |
REX LODGE | Formally lodges the REX with DAFF. Provided the message is not rejected the result could be a REX in any status from Initial to Completed. This may be the only required interaction with NEXDOC in a scenario where the user is not printing a certificate themselves (i.e. REX goes to Completed and certificate is not required or is printed elsewhere). |
REX AMEND | Amends the existing lodged REX to provide NEXDOC with updated details. This can be used to add information to a REX that has not yet been inspected and approved. Can only be used when a REX has been lodged (i.e. you cannot use this to amend an Order). |
REX READ CERTIFICATE | When the certificate is ready (CTRD or COMP status) this message type is used to download the certificate, in PDF format. This should be automatically sent when the certificate ready notification is received. The certificate is only returned once, and if sent again the response payload will not include the PDF certificate. |
REX READ | Used to update Prodoc data to match NEXDOC. The response payload is the full REX details and Prodoc will use these to update the RFP to match what is on file at the NEXDOC end. |
REX TRANSFER | Used to transfer the REX to another exporter. This does not necessarily mean changing ownership of the REX, although it typically involves changing both. The receiving exporter and party are specified in the Details screen. |
REX FORWARD | Used to change ownership of the REX (without changing the Exporter) |
REX TRANSFER EDN | Used to transfer just the EDN from one REX to another REX. The destination REX must have the customs agent indicator set to Y and have the EDN removed already in order to be a valid destination. |
REX CANCEL EDN | Cancels just the EDN associated with a REX, leaving the REX itself active. Can be used prior to transferring an EDN from another REX. |
REX WITHDRAW | Can be used to withdraw a REX that has not been inspected/approved. Used if the REX is no longer required. |
Notifications
Prodoc frequently checks NEXDOC for any new notifications. Where a notification relates to an existing REX it is added to the History for the RFP in Prodoc:
Notifications are received about events relating to the REX and will not always be immediately connected to an outgoing message. For example a REX being approved by an inspector or suspended by DAFF will result in a notification.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article