Customer POs drafted as Sage 100 sales orders, then set against the orders your desk saved.

Today someone opens Sales Order Entry, picks the order type, enters the customer and the buyer's PO number, chooses a ship-to code and works down the Lines tab: item, quantity, unit price, promise date. A release against a master order, or a PO that answers a quote, adds a step before any of that. Most of the minutes go into checking, not keying.

For the test, AI reads copies of POs your team has already entered and drafts each one in Sage 100's own terms, header, address and lines, with a note on why it chose each value. It saves nothing in Sage 100. Your reviewer then checks every draft against the order your team keyed at the time.

Which order type. Sales Order Entry offers a standard order, a back order, a price quote, a master order and a repeating order. Back orders usually aren't keyed by hand: Sage's help says they are created in Invoice Data Entry when fewer units ship than were ordered, with the shortfall moved to Back Ordered. A quote becomes an order when someone changes its type to Standard, and only then does inventory on sales order move; the header keeps a Promoted to Order On date. The draft says which type it would use for each PO, and why.

Master orders and their releases. For a customer buying a large quantity over time, a master order holds the total, and each shipment is a standard order that names the master in its Master/Repeating Order field. The master's lines track original quantity, balance, ordered to date and shipped to date, and its ship date field becomes an expiration date. The draft finds the master a release belongs to, shows the balance before and after, and holds a release that would overrun the balance or arrive after the master expires.

Their PO number and their part numbers. Sage 100 shows a message when a Cust PO number is already in use, and a user with the right security can look at the other documents or carry on. Item numbers are their own puzzle. An alias can be general or belong to one customer or vendor, aliases can be added on the fly in Sales Order Entry, and typing one puts your item code on the line. That makes a wrong alias easy to create and hard to spot later, so the draft shows the alias behind every line and marks any match it had to guess, for a person to confirm.

Ship-to codes carry more than an address. The Ship To Addr code fills the address from Customer Ship-To Address Maintenance, and the warehouse, ship via and salesperson can default from it. The tax schedule follows the ship-to ZIP code, so a job-site address typed over the default can change the tax on the order. The draft picks a ship-to code when the PO's address matches one on file, and labels anything else as an address change for your desk to approve.

Price, credit, and what your reviewer watches. Unit price comes from the item's price code, the customer's price level and any sale pricing, and changing it takes security. A customer on credit hold or over the limit brings up the Customer Credit History window, and an order held after that check carries Hold status with a reason code. The draft states the price it expected, the price on the PO and the gap, and notes when an order would meet a credit check. Your reviewer, usually the order desk lead or inside sales manager, looks hardest at aliases, master order balances and repeated PO numbers, since those decide what ships and what gets billed.

Once your reviewer finds the drafts meet the success criteria, incoming POs are drafted the same way for roughly 30 days.

Someone on your desk approves, corrects or returns each draft before an order exists in Sage 100. Approved orders get in the way your Sage 100 admin prefers: typed from the draft, or loaded through an import such as Visual Integrator where your company already licenses it. Credit release, picking and invoicing stay with your team.