Spring Foods Acumatica Customization Summary

A plain-language overview of what our Acumatica customizations do and why they exist. Organized by functional area; each section names the Acumatica screens involved and refers to fields by the labels users actually see.

Contents

Production Floor Execution

Screen: Move Transaction

The Move screen is where production operators record what they've made. Operators use iPads on the production floor, so the standard screen, was reworked to streamline touch operations. This is the most heavily customized area of the system.

Quantity Entry by Physical Unit

Rather than typing a number, operators tap a button that adds or subtracts one real-world unit of product: a tray, an oven board, a full deck oven rack, a full rack oven rack, a pallet, a packaging bread tray, or a stack of bread trays. Buttons appear only for units that actually apply to the item being made, and only while the entry is still open for editing.

A Copy/Paste Batch button duplicates the current line, so an operator recording several batches, oven racks, or pallets in one session doesn't re-enter the same information repeatedly.

Why it matters: operators count in trays and racks, not eaches. Letting them record what they physically see reduces both keystrokes and conversion mistakes.

Automatic Lot Numbers and Expiration Dates

Lot numbers and expiration dates are generated automatically according to our conventions rather than typed by the operator.

Expiration is calculated from the production date plus the shelf life defined on the item, so best-by dates stay consistent across every batch of the same product. Most Subassemblies and finished goods use the production date converted to a 5 digit Julian date [YYddd]. T&B and Frozen finished goods inherit the lot from the subassembly consumed that was produced at the previous work center. This preserves traceability from raw dough through to finished goods.

Why it matters: lot accuracy is a food safety and recall requirement. Removing manual entry removes the most likely source of error and reduces the amount of key strokes operators are expected to perform on the production floor.

Follower Label, Case Label, and Pallet Tag Printing

A Print Batch Label button sends the correct label and pallet tag directly to the right printer on the floor. Which label prints and which printer receives it is determined by the production order type, the item class, and the item itself. Some products, such as our T&B and Frozen class SKUs, require both a case label and a pallet tag, and both are sent automatically. The button becomes available once the move has been released.

Why it matters: operators don't have to know which of several printers or label formats applies to the product they're running. This also creates a stage gate where the required labels for the next work center are only made available once the current work center enters the transaction in the system.

Over-Production Approval Gate

If a production entry would complete more than 110% of what the production order called for, the operator is warned and told exactly how many units over they would be. Continuing requires supervisor approval captured on the entry itself: Over Production Qty, Over Prod. Approved By, and Over Prod. Approval Nbr, which must match the production order being over-produced.

Why it matters: most large overages are data entry mistakes. Catching them before release avoids inventory corrections after the fact. Genuine overages still go through, but on the record and with a name attached.

Quality Rejections and Waste

Operators record rejected product using Qty Shorted/Rejected, Shortage Reason, Short/Reject UOM, and Rejected Item ID. These fields replace Acumatica's built-in scrap function.

Why it matters: the native scrap feature writes off the item being produced at the current step, including its packaging materials. That isn't what actually happened. What operators are rejecting is the subassembly received from the previous work center typically unpackaged product sent from Bench / Baking. Using the native feature produced inaccurate inventory write-offs and distorted material costs. The custom fields record the rejection against the correct item.

A move with zero good quantity can still be released when a rejected quantity is present. This allows operators to record waste separately from attainment when needed, including recording waste against multiple reason codes.

Entry Default Values

The operation defaults to the last step in the BOM routing, which is what allows the system to automatically back-report the earlier steps. For mixing orders, the quantity is pre-filled with the calculated batch size.

Why it matters: Reduces the number of transactions and keystrokes required by an operator on the production floor.

Transaction Release Safeguards & Custom Errors

Moves cannot be released while a physical inventory count is running at that warehouse. The native acumatica behavior is intercepted and Operators see a clear message telling them to leave the page open and try again in about ten minutes.

When a release does fail, the error message is rewritten to name the actual items involved rather than showing internal ID numbers, and the last error is stored on the batch so it can be reviewed later.

Why it matters: The native acumatica behavior produces an error with technical details that can be difficult to understand. Releasing during a count can create allocation conflicts and potential corruption of the count results. It has also been documented that releasing during a PI can create transactions that are in a partially released state which can require multi step corrections. The message is written to prevent the operator's natural reaction of closing the page and starting over. This would lose their work and also leave an unreleased transaction that could prevent closing the order in a timely manner.

Production Order Management

Screens: Production Order Maintenance, Release Production Orders

Linking Parent and Subassembly Orders

Production runs span multiple orders from starters -> doughs -> Shaped/Baked WIP -> Finished goods. The system creates a hard link from each order to the subassembly order that feeds it, showing Subassembly Prod Order, Subassembly Inventory ID, Subassembly Order Type, Subassembly UOM, and Qty Sent from Prev WC directly on the parent order. Orders belonging to the same run are identified by their shared start date. The link can be created for many orders at once from the Release Production Orders processing screen.

Why it matters: without the link, tracing what fed what means manually matching orders by date and item. This puts the upstream order one click away and shows how much actually came forward from the previous work center.

Production Visibility in Batches

For mixing orders, quantities are displayed as batches as well as pounds — Total Batches, Batches Complete, and Batches Remaining.

Why it matters: mixing is planned as pounds but tracked as batches on the floor. This allows visibility at the batch level of what was completed and what remains using the unit that mixers naturally track.

Rejection Visibility

Rejections recorded on the floor roll up to the order as Qty Shorted/Rejected, with a detail grid listing each individual rejection.

Recording Moves After Completion

A Create/Correct Move button is available in the order header at all times, including after the order has been marked complete.

Why it matters: corrections are often discovered after the fact. The standard screen hides the option once an order is completed.

Production Planning

Screens: Master Production Schedule, Inventory Planning Display, Regenerate MRP

Our planning model is a hybrid. Fresh bread for DSD customers is planned daily against consolidated sales order demand on a two day lead time; other products are built to inventory on a multi-week lead time. Standard Acumatica planning is best configured as one model or the other, so the functionaility was extended to handle both together via a controlled workflow that utilizes a modified Master Production Schedule.

The Daily Workflow: After the order cutoff, the planner imports the day's sales order demand for fresh bread items requested two days out. The planner then adds the planned production items to the MPS manually. Together these records become tomorrow's production schedule.

Dough Weight Visibility

Each scheduled item shows the Estimated Weight of dough required, along with the related Dough Item ID, or for T&B Finished Goods the T&B WIP SKU and the WIP Qty Available in the warehouse. A Total LBS figure at the bottom of the schedule sums everything currently marked active.

Why it matters: the schedule is built with units of finished goods and T&B WIP, but the constraint is total daily pounds measured by dough weight. The planner needs to see the pounds implied by the items / qty on the MPS while building the schedule, not after.

Production Line Routing

The planner can choose a BOM Revision for each scheduled item, selecting the BOM version that matches the packaging line the product will actually run on.

Why it matters: the same product run on different lines consumes different packaging materials. Choosing the revision up front means the right materials are backflushed automatically. The system also keeps separate schedule lines for the same item and date from being merged into one production order, so split runs, meaning half on one line, half on another, will stay split.

Production Order Creation and Sizing

When the planner creates production orders from the Inventory Planning Display, the customization applies our sizing rules:

  • The order type defaults to the item's Prod Ord Type.
  • Quantities below the item's Min Batch Size are raised to the minimum.
  • When Default to Max Batch Size? is set, the quantity is rounded up so every batch is a full Max Batch Size. For example: 1,400 lbs of demand against a 500 lb maximum would otherwise mean two full batches and one 400 lb batch. Instead the order is raised to 1,500 lbs for three even batches.

Why it matters: partial batches are inefficient to mix and produce inconsistent product. Small orders below the minimum cannot be effectively mixed in our mixers.

The production order number created is written back to the Master Production schedule line, and the line is deactivated so the same demand can't generate a duplicate order.

Skipping Items

An item flagged Do Not Make is skipped during planning even when demand exists. The flag is set on the item and enforced on the schedule. This allows us to prevent the production of these items in the event of a material shortage without changing the status of the Stock Item to Inactive. Changing the status can prevent other valid transactions for that item from being created and released.

Planning Date Correction

A defect introduced in an Acumatica 2025 R2 patch caused production orders to be created with dates pushed earlier by one day for every level of the recipe — up to five days early in our environment. A fix corrects these dates during planning, with a second safeguard on the planning screen.

Why it matters: without it, the production orders would be created for past days and will not consolidate or display properly on production reports and commonly used screens by the operators on the floor.

Item Setup and Data Governance

Screens: Stock Items, Non-Stock Items, Item Classes

Several fields on the item record drive production behavior elsewhere in the system:

  • Max Batch Size and Min Batch Size — the most and least dough allowed in a single mixing bowl, in pounds. These drive order sizing during planning and quantity defaults on the floor.
  • Default to Max Batch Size? — forces production orders into even, full batches.
  • Prod Ord Type and Default MPS Type — how the item is scheduled and produced by default.
  • Fermentation Time — the standard fermentation time for a dough or starter, printed on follower labels so the floor knows the window in which the dough should run through the shaping line.
  • Ingredient Statement — the ingredient statement text matching the product packaging, used to generate QA-compliant case labels.
  • Do Not Make — excludes the item from production planning.
  • Sales Class — an additional classification layer between item class and sales category, used for external sales reporting.

Item Sales Classes

Sales classes are maintained on their own screen, separate from item classes. They are a deliberately loose classifier related to both item class and sales category, used mainly for external reporting and Power BI. A class still assigned to items cannot be deleted.

Why it matters: item classes are wired into workflows and custom logic throughout the system, so adding or changing one has consequences that have to be traced and accounted for first. Sales classes carry none of that coupling, which gives reporting a dimension that can be reorganized freely without risking production behavior.

New Item Review

Newly created items default to an inactive status. Someone with the appropriate permission must review the setup before the item can be used.

Why it matters: an item with a missing production details, no standard cost, or other critical details creates financial inaccuracies from the moment it goes live. This forces a review first.

Physical Inventory Counts

Screens: Physical Inventory Count, Physical Inventory Review

The GTIN — the barcode number on the product — is displayed on both the count entry screen and the review screen.

Why it matters: External warehouses and logistics teams maintain inventory by the details displayed on the case. Showing the GTIN alongside the internal item ID lets us map PI Count entries to external reporting to prevent inventory adjustment mistakes.

Order Management

Screen: Sales Order Entry

Delivery Day Validation

Each customer has defined days they can receive deliveries, shown on the order and customer attribute as Cust Delivery Days. If someone enters an order for a day that customer doesn't receive deliveries, the order is stopped at entry. Individual products can also be restricted to certain days with the Item Del Days attribute to account for items that have set scheduled production days.

Why it matters: an undeliverable order still generates production demand. We'd produce product that can't ship, and discover it a day later. Catching it at entry prevents both the waste and the customer service problem.

Duplicate Order Prevention

If an order already exists for the same customer, location, and delivery date, the person entering is prompted rather than allowed to create a second one, and can jump straight into the existing order with an Edit Existing Order action.

Reusing a customer PO number that already exists in the system also raises a warning.

Why it matters: duplicate orders double production demand and ship twice.

Entry Defaults

For sales orders on the EBC branch, the order type and dates are pre-set to match how those orders actually work — requested date defaults to two days out, matching our standard fresh bread lead time.

Recurring Sales Orders

Screens: Recurring Sales Order Maintenance, Generate Recurring Sales Orders

Many DSD customers order essentially the same products, in the same quantities, on the same days every week. Rather than keying those orders in day after day, a standing template is set up once per customer and location, and sales orders are generated from it on demand.

This is a purpose-built module rather than a modification of an existing screen — it has its own maintenance screen, its own generation process, and its own audit log.

Setting Up a Standing Order

Each template is tied to one Customer and Customer Location, with an Order Type and a Description, and can be switched on or off with an Active flag.

Beneath the header, one line is added per product. Each line carries the Inventory Item, UOM, and Unit Price, plus a quantity for each day of the week — Sun through Sat. A zero on a given day simply means the customer doesn't take that item that day.

Selecting an item fills in its default unit of measure and suggests the current list price, so the person building the template isn't looking up either one.

Why it matters: a week's ordering pattern for a customer lives in a single record. Changing a standing quantity is one edit rather than a change repeated across every future order.

Temporary Holds

A customer or location can be placed on hold for a single date or a date range, with a Hold Start Date, Hold End Date, and a Reason. Leaving the location blank puts every location for that customer on hold.

Why it matters: customers close for holidays, remodels, and vacations. Without a hold, the generation process would create orders for a store that can't receive them, and someone would have to find and cancel each one. Setting a hold ahead of time prevents the orders from ever being created.

Generating the Orders

The generation screen takes a Start Date and End Date, optionally narrowed to a single Customer or Location. It lists every active standing order matching the filter; the user selects which to run and processes them.

For each standing order and each date in the range, the system works out the day of the week, pulls that day's quantities, and creates a sales order if there's anything to order. Customer terms, tax zone, currency, shipping address, warehouse, pricing, and taxes all populate exactly as they would if the order had been keyed by hand.

Three things will stop an order from being created:

  • A sales order was already generated for that standing order and date. The Skip Already Generated Dates option controls this guard.
  • An active hold covers that customer, location, and date.
  • No item on the template has a quantity for that day of the week.

Why it matters: the duplicate guard is what makes the process safe to re-run. If someone runs the same date range twice, or a run fails partway through and is restarted, customers don't receive doubled orders.

Audit Log

Every attempt is written to a log showing the Order Date, the resulting Sales Order Nbr., a Status, a Message explaining any skip or failure, and when it was Generated On.

Why it matters: when a customer says they didn't get their order, the log answers whether one was generated, skipped for a hold, skipped as a duplicate, or failed — without having to reconstruct what happened.

Entry Safeguards

A standing order cannot be marked active unless at least one line has a quantity on at least one day. Hold end dates cannot precede their start dates, and the same rule applies to the generation date range.

Why it matters: an active template with no quantities would be picked up on every run and silently produce nothing. Catching it at entry means the person setting it up finds out immediately, rather than a customer discovering it when nothing arrives.

Shipping and Fulfillment

Screen: Shipments

DSD Lot Nbrs

For fresh DSD products, the lot number is generated at shipment creation with its own unique lot convention. This convention consists of the best by date, production date, "DSD" mark, and auto incrementing number. The best by date matches the date printed on the Qwik Lock and is the first segment of the lot nbr.

Why it matters: DSD product is dated and optimized for the distribution team. This allows our CSR team to easily match the date on the qwik lock with the lot nbr they are processing a return for when creating credit memos in the field.

Fulfillment Filtering

Shipments display the Customer Class ID and a Has R&I Items flag indicating whether the shipment contains food service products.

Why it matters: packaging pick lists and reports are generated by product type, customer type and route id. These fields let the teams filter processing screens down to the right set of shipments.

Receiving and Traceability

Screen: Purchase Receipts

Lot numbers on received raw materials are generated automatically using the purchase order number as the leading segment, followed by an organic or conventional indicator and a sequence number.

Why it matters: The lot number itself tells you which PO, and therefore which supplier and delivery the material came from. That makes supplier traceability a lookup rather than an investigation.

Finance and Customer Deductions

Screens: Payments and Applications, Invoices and Memos, Bills and Adjustments, Journal Transactions

Applying Customer Payments

Most DSD customers reference either the sales order number or their mobile-commerce transaction number on their payment remittances, not the Acumatica invoice number. AR clerks can enter either SO Nbr. or XMC Tran No. when applying a payment, and the system finds the matching invoice.

Why it matters: without this, every remittance would requires a manual lookup to translate the customer's reference to ours. This is high-volume, repetitive work across hundreds of DSD accounts and invoices per day.

When payments are imported rather than keyed, applications that don't cover the full document amount are flagged for manual handling instead of automatically posting with a short paid amount.

Vividly Integration / Deduction and Settlement Tracking

The customer's Remittance Nbr. is recorded on payments and on AR documents as a key identifier for the Vividly integration, used in the data set sent to vividly that consists of credit memos or payment applications that represent deductions, promotions, and allowances that Vividly has not yet settled.

Manual journal entries carry a Customer field on each line so that deduction settlements can be attributed to the customer they belong to.

Why it matters: trade deductions are a significant cost of doing business and can create visibility issues into trade spend performance. Attributing them to the right customer improves customer-level margin and contribution margin accuracy.

Credit and Debit Memos

Standalone credit and debit memos can be linked back to the originating sales order and, where relevant, to a stock item. Inventory-related credit memos default to the Returns and Spoils account rather than standard sales.

Why it matters: returns and spoilage are tracked separately from sales revenue, and the default removes a per-transaction judgment call from AR.

Deductions billed back to a customer through Accounts Payable can carry the related SO Order Nbr. and Customer, tying the payable to the order it came from.

Edit this page