Eniteo 13.02.31 extends the EDI framework with full Material Test Report (863) support, so service centers can receive test data from mills and trading partners directly onto their heat and tag records and send it to customers as a separate EDI document alongside the Advance Ship Notice. Toll Processing billing now works master by master, giving each processed coil or piece its own invoice detail. The release also delivers refinements across shipping, warehouse transfers, vendor payments, receiving, and payments tax reporting.
EDI Material Test Report (863) Support
The EDI integration Eniteo built with Foundational now carries a second document type: the Material Test Report (863). MTRs are exchanged in both directions, alongside the Advance Ship Notice (856). Inbound, an MTR from a mill or trading partner brings chemical and mechanical test data straight onto your heat and tag records. Outbound, Eniteo sends an MTR to a customer as its own document at ship time, so test data travels with the shipment as EDI. If your deployment is not set up for EDI yet, see EDI: Getting Started with Foundational.
Enabling MTR. MTR follows the same enablement pattern as the ASN. Turn the document type on for your deployment in Application Control > EDI, then enable it per trading partner for outbound documents. Inbound and outbound MTR are set independently, so a deployment can run either or both. See EDI: Configuring EDI in Eniteo for the full reference.
Receiving MTRs from mills and vendors. Like the ASN, an MTR can travel in either direction, and the two are worked in different places. An inbound MTR is handled in Receiving, in the same queue as inbound ASNs, where its test data is imported onto material you have already pre-received or received. The queue opens from Receiving > Pre-Receive Import.
Review and import inbound MTRs. Inbound MTRs arrive shown as MTR (863) in the Doc Type column. They are imported and rejected with the same actions as an ASN. For the full receiving workflow, see EDI: Receiving — Inbound MTR (863).
How physical and chemical properties are imported. An inbound MTR lands mill test data on the records that carry it, with no one retyping a certificate. Eniteo matches the heats on the document to material you have already pre-received or received. Chemistry is written to the heat record, and mechanical results are written to the tag, one entry per specimen. From there the values appear wherever Eniteo already shows heat and tag data, including the heat file and the Letter of Compliance. They also become search criteria: the detailed search in Command Center and Inventory Lookup has Chemistry and Physical Properties tabs, so you can identify material that matches a customer's spec. For the field-by-field detail of what an MTR carries and where each value lands, see EDI: MTR (863) Data Reference.
An MTR needs no further review once it is imported. A successful import loads the test data straight in and moves the document to the Imported tab.
Sending MTRs to customers. An outbound MTR is handled in Shipping, and goes to the customer alongside the ASN when a load ships. A customer receives one once MTR (863) is checked in the EDI Documents Outbound box on their Batch Processing (F6) tab, alongside the existing ASN (856) setting.
A load going to an EDI trading partner sends its MTR from the same Print Reports flow that sends the ASN. The EDI option there counts the customers on the load set up for any outbound EDI document.
The EDI Export window lists every document going out for each customer on the load, with the load's document count and the customer's Bill of Lading. Both documents for a shipment carry the same Bill of Lading reference. Each document is sent and reports its own status, so a shipment carrying both an ASN and an MTR confirms each one separately.
A document that has already gone out can be resent on its own, with a record of when it was last sent and by whom. For the full shipping workflow, see EDI: Shipping — Outbound MTR (863).
Improved Toll Processing Billing Detail
On a Toll Processing order the customer keeps title to the material and you bill for the processing. An order can take more than one master to fill. Toll billing worked from a single invoice line for each sales order line. That suits an order filled by one master. Billing is now structured per master: a sales order line filled by several masters produces a material line for each of them, carrying its own pieces, weight, price, and dimensions. Where scrap is produced and a scrap credit rate is configured for the material, that master's scrap credit sits directly beside its material line. The pairing holds on the invoice, the pre-register, the register, and every reprint, under the Bill of Lading for the load it shipped on.
A Toll order filled from material on hand, without a production order, still bills as a single line. Existing invoice history is updated at upgrade, so older Toll invoices reprint with the same detail.
The invoice below covers a single sales order line filled by two masters. Each master has its own material line, and each is followed directly by the scrap credit for that master.
A master at a time. The Billing Trigger setting on the Toll Pricing panel of a sales order line decides when that line bills — Production Completion or Shipping. New lines follow the Default Toll Billing Trigger set in Application Control. Production Completion invoices each master as it finishes; Shipping invoices the material on the current load and then ties that invoice to the load. Either way a master bills once, whether the masters finish together or in separate runs, and completion events on the same sales order line can go on separate invoices. Shipping draws only on the masters allocated to the current load, so a master held back for a later load is left untouched. A master with an unbilled line still sitting in Billing is named by Post Production so it can be billed first.
Billing per master carries through the rest of the order:
- The rest of the order stays shippable. A sales order line stays open while any master line is unbilled or unshipped, so the remaining quantity sits in Load Open Orders (F5) ready for a later load. The line completes once the full ordered quantity has shipped.
- A shipment's lines bill together. Open lines from one sales order line on one load form a single billing group. Selecting any line selects the group, and clearing any line clears it. The group posts to one invoice in one Billing update, so a scrap credit is never invoiced without its material line. Separate loads and separate sales order lines each form their own group.
- Shipment amounts are counted once. Freight is one cost of moving one load, so freight and shipment weight are recorded once for the shipment, no matter how many masters are on it. The shipment also keeps one entry in shipment history. That freight is divided across the material lines by weight and sums exactly back to the shipment, with scrap-credit lines carrying none of it.
- Pricing is counted per master. Each line is priced on its own master's weight — net, or gross including that master's scrap, per the pricing basis on the process — and customer surcharges are figured line by line.
- Bills of Lading show one shipment. A Bill of Lading shows one shipment detail with all of its tags, before billing, while queued, and on reprint, and Freight Out reconciles once for each BOL.
- Unshipping waits for billing. A load cannot be unshipped while any line for its sales order line is queued or billed, and Eniteo reports which lines are holding it. Unshipping reopens once those lines post or clear the queue.
Bug Fixes
- Avalara Tax: Fixed an issue where quotes and orders created through the EAPI with an Avalara tax code calculated freight tax even when every material line was exempt. Freight tax now follows the taxability of the order's material lines, and existing open Avalara documents are repriced so their persisted totals match.
- Command Center: Fixed an issue where cancelling a line on an order using a flat freight amount reduced the freight figure in the Command Center totals by the cancelled line's share. The totals footer now shows the full entered freight amount, matching the printed sales order and the invoice.
- Production Order Entry: Fixed an issue where removing all BTS lines for a sales order line shared across multiple masters prevented that line from being added back to the grid and reported the production order as locked. The line can now be re-added in the same session without going through Clear Old Program Locks.
- Production Order Reports: Fixed an issue where a production order line comment printed once for each master tag allocated to the setup on the Production Order and Production Order By Priority reports. Each line comment now prints once per line.
- Receiving: Fixed an issue where committing a pre-receive returned a system error when the Foreign checkbox was selected on a line. Pre-Receive Commit now completes with the Foreign setting applied.
- Sales Tax Reports: Fixed an issue where the sales tax on credit card surcharge debit memos generated through Enmark Pay Online was omitted from the Sales Tax Detail by Invoice Line, Sales Tax Detail, and Sales Tax Summary reports. These reports now include the surcharge tax from Enmark Pay Online debit memos, so their totals match the tax posted to the Sales Tax Payable GL.
- Shipping: Fixed an issue where creating loads in Shipping produced lock contention that reached programs outside Shipping. Load creation now holds database locks for a much shorter time, keeping other programs responsive during heavy shipping activity.
- Vendor Payments: Fixed an issue where an Invoice Payment or Discount Amount keyed or pasted to three decimals was retained at that precision in Vendor Payment Edit and Vendor Payment Invoice Selection, causing the check run update to roll back. Both amounts are now stored at two-decimal precision, and Create Checks and Update complete successfully.
- Warehouse Transfers: Fixed an issue where the From and To warehouse fields remained editable after a transfer line was allocated, added to a load, completed, shipped, or sent through the approval workflow. Both fields are now read-only in those states, keeping tag allocations aligned with the From warehouse.
- Warehouse Transfers: Fixed an issue where the Approval column truncated the Requested On transfer number when a pending request line was first inserted into the Inventory Transfer Lines grid (F3). The column now sizes to show the full transfer number as soon as the line is added.