Produce Bills Setup

These settings control how produce bills are generated, grouped, calculated, and posted.

Produce Bill Source Code

Specifies the source code applied to general ledger entries created when produce bills are posted. Used to identify and filter bill-related transactions in the general ledger.

Use Purchase Percentage Calc. on Bill

  • OFF (default): Standard rates are calculated and applied before bill amounts are determined. No additional standard rate calculation runs after bill amounts have been applied.

  • ON: The normal standard rate calculation cycles run first, bill amounts are then applied, and an additional dedicated cycle runs after that — calculating only those standard rates that are configured to calculate as a percentage of the purchase price.

Note

Enabling this setting can impact processing time, particularly when large numbers of price adjustments are imported from the produce bill sheet.

How bill grouping works

When bills are generated, the system groups pallet lots into bills using a combination of built-in grouping keys and two configurable settings (Channel Basis and Grouping Basis, described below).

Built-in grouping keys (always applied, not configurable):

  • Lot Billing Party — the vendor the bill is being raised for
  • Lot Billing Type — whether the bill is for a vendor or a customer
  • Commodity Group — the commodity group of the pallet lots
  • Currency — the intended purchase currency of the pallet lots

Configurable grouping dimensions (controlled by the settings below):

  • Channel Code — the inbound or outbound channel, depending on the Channel Basis setting
  • Grouping Basis Value — the specific week number, trade code, or custom code, depending on the Grouping Basis setting

All of these dimensions must match for pallet lots to land on the same bill.

Example — 30 pallet lots, two vendors

To illustrate, imagine 30 pallet lots from two vendors (Vendor A and Vendor B), all the same commodity group and purchase currency. All pallets entered through the same inbound channel (L), but some were directed to outbound channel E and others to outbound channel L. They arrived in different estimated arrival weeks and were sold through different produce trades.

With Channel Basis = Outbound and Grouping Basis = Estimated Arrival Week, the system creates 6 bills — because both outbound channels (E and L) are present, the channel dimension splits each vendor’s pallets further by their arrival week:

Vendor Outbound Channel Est. Arrival Week Pallets Resulting Bill
Vendor A E 6 9 Bill 001
Vendor A E 7 2 Bill 002
Vendor A L 7 4 Bill 003
Vendor B E 6 10 Bill 004
Vendor B E 7 2 Bill 005
Vendor B L 7 3 Bill 006
    Total 30  

With Channel Basis = Inbound and Grouping Basis = Confirmation Week, the result is different — because all pallets share the same inbound channel (L), the channel dimension does not split them further. The split comes entirely from the confirmation week:

Vendor Inbound Channel Confirmation Week Pallets Resulting Bill
Vendor A L 1 5 Bill 001
Vendor A L 2 5 Bill 002
Vendor A L 3 5 Bill 003
Vendor B L 1 4 Bill 004
Vendor B L 2 6 Bill 005
Vendor B L 3 5 Bill 006
    Total 30  

With Channel Basis = Outbound and Grouping Basis = Produce Trade, the result is 8 bills — the Produce Trade dimension produces more unique combinations than the arrival week in this dataset:

Vendor Outbound Channel Produce Trade Pallets Resulting Bill
Vendor A E Trade 1 4 Bill 001
Vendor A E Trade 2 5 Bill 002
Vendor A E Trade 5 3 Bill 003
Vendor A L Trade 5 3 Bill 004
Vendor B E Trade 1 6 Bill 005
Vendor B E Trade 2 4 Bill 006
Vendor B E Trade 3 2 Bill 007
Vendor B L Trade 4 3 Bill 008
    Total 30  

Produce Bill Channel Basis

Controls which channel code — inbound or outbound — is used as one of the configurable grouping dimensions when bills are generated:

  • Inbound: bills are grouped by the pallet’s inbound channel code (how the produce came in from the supplier)
  • Outbound: bills are grouped by the pallet’s outbound channel code (how the produce was directed to market)

Cost Produce Bill Grouping Basis

Controls the second configurable grouping dimension when cost produce bills are generated. Options:

  • Harvest Week — grouped by the week the produce was harvested
  • Pack Week — grouped by the week it was packed
  • Inspection Week — grouped by the week it was inspected
  • Confirmation Week — grouped by the week the pallet file was confirmed
  • Estimated Departure Week — grouped by the estimated freight departure week
  • Actual Departure Week — grouped by the actual freight departure week
  • Estimated Arrival Week — grouped by the estimated arrival week
  • Actual Arrival Week — grouped by the actual arrival week
  • Produce Trade — pallets are grouped by produce trade; because the billing party is always a built-in grouping key, a trade that includes pallets from multiple vendors will produce one bill per vendor per trade
  • Custom Group — grouped by a custom grouping code assigned to each pallet lot
  • Pooling Group — grouped by pooling group assignment

Advance Produce Bill Grouping Basis

The same grouping options as the Cost Produce Bill Grouping Basis, but applied specifically when advance bills are generated. This allows advance and final (cost) bills to follow a different grouping basis — for example, generating advance bills per inspection week while grouping final bills by arrival week.

Always Calculate Bill Costs

Controls whether pallet charges are calculated regardless of the status of the linked produce trade.

This setting applies to cost bills only. Advance bills never include pallet charge calculations, and forecast bills always do — both regardless of this setting.

  • OFF (default): Pallet charges are only calculated when the linked produce trade meets certain conditions. This is a safeguard that prevents pallet charges from being finalised before the sales side of the transaction has reached the required state.

    • When Defer Sales is ON (recommended): The produce trade must be in a Closed status before pallet charges will calculate. Charges are blocked for as long as the trade remains open or in progress.
    • When Defer Sales is OFF: The condition is less strict — pallet charges will calculate as long as at least one trade entry has been posted against the pallet. Full closure of the trade is not required.

  • ON: Pallet charges are calculated unconditionally on cost bills, regardless of the state of the linked produce trade. This bypasses the safeguard above. Note that calculation and posting are separate steps — this setting controls only whether charges are calculated; whether those charges are ultimately included when the bill is posted is determined separately at posting time.

Advance Reversal Method

Controls how advance payments are handled when the final produce bill is posted:

  • Nett Invoice: The advance amount is deducted within the same final invoice. The vendor ledger shows a single net invoice amount (final cost minus advance).

  • Credit Memo: A separate credit memo is posted to reverse the advance. The vendor ledger shows two documents — the final invoice and a distinct credit memo — providing a clearer audit trail of the two transactions.

Calc. Bill Job Category Code

The job queue category used when produce bill cost calculations are scheduled to run automatically in the background. Must match a category configured in the job queue setup.

Force Latest Bill Posting Date

Controls how the bill’s posting date interacts with the trade entries and actual pallet charge entries considered during bill calculation.

  • OFF (default): The bill’s posting date remains exactly as the user set it. When Calculate Charges runs, the Net Trade Amount is calculated using only trade entries posted up to and including that date. During the prioritisation step, actual pallet charge entries beyond the bill’s posting date are similarly excluded. Any trade entries or actual pallet charges posted after that date are ignored — the bill calculates as at the posting date the user specified.

    This caters for businesses that want to produce and post bills for a specific accounting period — only sales and charges that fall within that period are included in the bill calculation.

  • ON: Before calculating charges, the system scans all pallet lots on the bill and finds the latest posting date across all related trade entries and all related actual pallet charge entries. If that latest date is later than the bill’s current posting date, the bill’s posting date is automatically advanced to that date. The date filter then applies to this updated date, ensuring that all trade entries and actual pallet charge entries are taken into account.

    This safeguards against situations where a bill was created early — for example with a posting date of 3 April — but trade entries and actual charges were only posted later, on 7 April and 14 April. Without this setting, those later entries would be excluded from the calculation.

Set Document Date to Work Date on Release

  • OFF (default): The document date on the produce bill remains as originally entered, even when the bill is released.

  • ON: When a produce bill is released (status changes from Draft to Released), the document date is automatically updated to today’s work date. Ensures all released bills are dated as of their release date.

Detail Account Sale Posting

Controls how sales revenue and prioritised charges are handled when a consignment cost bill is posted.

  • OFF (default): Sales revenue and prioritised charges are posted via a background general ledger journal when the bill is posted. The purchase document generated by the bill contains only the final bill amounts (what the vendor will be paid), any advance reversals, and recharges. Recommended for most businesses.

  • ON: Sales revenue and prioritised charges are not background-posted but are instead transferred as individual lines to the purchase document. The bill amounts themselves are not transferred to the purchase document — because sales revenue less the negative charge lines already equals the bill amount. Each prioritised charge line on the purchase document carries its own VAT posting group, which allows different VAT treatment per charge type.

    The main reason to enable this setting is when the purchase document itself must serve as a formal tax document — for example, where a commission charge is subject to VAT that must be reflected in the purchase invoice and passed through to the vendor:

    Line Amount
    Sales revenue 1,000
    Prioritised costs (no VAT) -200
    Prioritised costs (VAT applicable) -100
    Net excl. VAT 700
    Net incl. VAT 685

    Note

    If the goal is simply to give vendors a transparent view of sales revenue and costs, this setting is not required — the same detail can be surfaced on the payment advice and advice data sheet, which is what vendors typically receive. The purchase document itself is not routinely sent to vendors.

Allow Bulk Bill Posting

  • OFF (default): Produce bills must be posted individually.

  • ON: Enables posting multiple produce bills at once as a batch job submitted to the job queue. Users can select multiple bills on the list and post them all in one action, which the system processes in the background. Requires that the job queue is correctly configured in Purchase & Payables Setup (Post with Job Queue and a Job Queue Category Code must be set). Significantly faster when posting large volumes of bills.

Common Income Incoterm Level

Used for reporting purposes only — specifically in the export produce bill sheet. It has no effect on any bill calculations or posted amounts.

Businesses often sell pallets under different incoterms — for example DDP, CIF, FOB, and DIP. Because each incoterm represents a different point in the supply chain at which costs transfer to the buyer, revenue figures across these incoterms are not directly comparable. This field allows a common normalised income level to be defined so that revenue can be compared on an equal basis across all pallets in the bill sheet, regardless of which incoterm they were sold under.

When configured, the produce bill sheet includes an additional column showing the income at the specified incoterm level, calculated by taking the sales revenue and deducting all costs that sit above that level. A corresponding gross profit percentage column is also added.

Example:

If this field is set to 03-DIP, the bill sheet will show a 03-DIP Income column. For every pallet — regardless of whether it was sold DDP, CIF, or FOB — the income is normalised by stripping out all charges above 03-DIP level, giving a comparable revenue figure at that point in the supply chain.

If this field is left empty, no meaningful output is produced for those columns. Configure it only if the business requires normalised incoterm income for reporting.

Ignore Income Percentage Levels

Applies only when the business has multiple pallet charges configured with a calculation method of Income Percentage at different incoterm levels. If only one such charge exists, this setting has no effect on the outcome.

Income percentage charges are always calculated at their individual incoterm level — the base amount for each charge is the trade revenue minus any costs already prioritised at higher levels. What this setting controls is whether higher-level income percentage charges are prioritised before lower-level ones are calculated, creating a cascade effect.

  • OFF (default): Income percentage charges are processed in descending incoterm level order. After each charge is calculated, it is immediately prioritised. When the system moves to the next charge at a lower level, the previously prioritised higher-level charge is included in the costs deducted from the base — so higher-level income percentage charges reduce the calculation base for lower-level ones.

  • ON: All income percentage charges are calculated first, without any intermediate prioritisation. When a lower-level charge calculates its base, no other income percentage charges have been prioritised yet — only regular cost charges reduce the base. Each income percentage charge calculates independently of the others, then all are prioritised at once.

Example

A pallet is sold at 07-DDP for a trade value of 1,000. Sea freight (06-CIF level) costs 300. The business has two income percentage charges: a DDP Commission at 07-DDP level (5%) and a FOB Commission at 05-FOB level (10%).

With Ignore Income Percentage Levels = OFF:

  1. DDP Commission (07-DDP) is calculated first — no prioritised costs above 07-DDP — 5% × 1,000 = 50. Immediately prioritised.
  2. FOB Commission (05-FOB) calculates next. Costs above 05-FOB = sea freight (300) + DDP Commission now prioritised (50) = 350. Base = 1,000 − 350 = 650. 10% × 650 = 65.
  3. Total income percentage charges: 115

With Ignore Income Percentage Levels = ON:

  1. DDP Commission (07-DDP) — no prioritised costs above 07-DDP — 5% × 1,000 = 50. Not yet prioritised.
  2. FOB Commission (05-FOB) calculates. Costs above 05-FOB = sea freight (300) only — DDP Commission not yet prioritised. Base = 1,000 − 300 = 700. 10% × 700 = 70.
  3. Both charges are prioritised at once.
  4. Total income percentage charges: 120

Note

This setting is independent of the Common Income Incoterm Level field, which is a reporting tool only.