Summary

Abstract

The purpose of payment proposals is to force customers with bad credit limits and customers without an account to pay cash before any goods can be dispatched. The cash payment is made against a payment document instead of an invoice to prevent accounts receivable from containing claims that will never be paid. The payment is booked as an on-account payment and later, when the invoice is issued, is automatically reconciled.

Different sourcing requires different types of payments. A stock order requires full payment before the delivery can be released for picking; a non-stocked order requires the customer to pay an advance amount in order to release the planned acquisition orders. These include planned purchase orders, planned distribution orders, planned manufacturing orders, and planned work orders. When the customer order allocates the available stock, it must be paid in full like a normal stock order for these types of customers.

Background

A possible business workflow for payment proposals is when a customer walks into a store; a salesperson specifies a customer order and provides the customer with a payment document. The customer brings the payment document to the cashier and pays. Finally, the customer retrieves the ordered goods at the pickup location. Since the customer might walk out of the store without paying, accounts receivable may not be updated prior to payment. An automatic closing routine that updates lost sales and releases allocated stock is also required.

Limitations

• A summary invoice cannot be created for a customer order with the payment document workflow.
• An invoice can only have one payment document number.
• Cash discounts are not supported in the payment document process.
• Corrective invoices are not supported in the payment document process.
• Payment documents cannot be paid from a full screen processing view (sorting orders 11-16) in (ARS110).
• In 'Voucher. Reverse' (GLS900), the transactions only apply to accounts receivable and the general ledger. No update is performed to the order tables.
• Catch weight invoices are not supported in the payment document process.
• Kit items are not supported in the payment document process. Both the kit header and the kit lines are displayed in the sub-file, but the quantity to pay is only editable for the kit header. The quantity to pay is rounded off to the next complete multiple of the complete kit.