This section lists the payment and refund options that are supported in the Point of Sale program and it describes how each payment or refund transaction is recorded by the system. Please note that a combination of payment methods can be used on a single POS Transaction. For example, you may process a payment that includes cash, check or credit card payments on the same transaction.
The Payment methods described in this section are only available when a customer with COD Terms is being used during POS processing. When a POS invoice or refund is processed for a COD customer, the POS program displays a “PAY” button.
Once you have entered the line item information for the POS invoice or refund and have entered or modified any other required information for the transaction, you may click the “PAY” button. This action will cause the system to display the POS Payment Panel. The POS Payment Panel allows you specify the payment method or methods to be used for the current POS invoice or refund.
When the POS Payment Panel is displayed it will show the amount of the invoice or return being processed in the Total window that is displayed in the panel. Any payments already entered will show in the Paid window, and any amount still due is displayed in the Due window.
Cash Payment
You may process a Cash Payment or Refund for a POS invoice or credit by using the Dollar amount Buttons or the “Other Amt”. “Exact Amount” and the “Clear Cash” Buttons in the POS Payment Panel. The amount of cash you enter is displayed in the Cash window in the panel.
The Dollar Amount buttons ($5, $10, $20) can be used to quickly indicate the cash amount received from the customer, and the cash amount is increased each time one of the buttons is pressed (ie pressing $20 three times will cause the system to show $60 in the Cash window
The “Other Amt.” button allows you to specify the exact amount of cash received from the customer. When this button is pressed, the system displays a numeric prompt object which allows you to enter the amount received. The amount can be typed direcly into the prompt or you may use the buttons in the prompt object to enter the appropriate amount.
The “Exact Amount” Button will default the invoice total or the remaining balance for the transaction into the cash window when it is pressed.
The “Clear Cash” Button clears out the cash amount displayed in the Cash window and it causes the system to recalculate the remaining amount due for the POS transaction.
Once the amount of cash being received (or paid out) is entered into the POS Payment Panel and any other payment amounts have been recorded, the Payment Panel will display the amount of change or the refund amount to be given to the customer in the Change Window. If the amounts shown are correct, you may save the payment information using the “DONE” Button. The system then verifies all required information has been entered for the transaction. If so, the transaction is saved, if not, the system will display an error to indicate that the transaction cannot be processed.
As a POS transaction that includes a Cash Payment or refund is saved, the system performs the following steps.
• The POS invoice or credit memo (for a return) is created and posted to the general ledger (sales, including POS Sales are normally posted to the GL on-line – but options also allow you to post sales by batch). The invoice or credit created by the POS system will reflect the payments or refunds that were processed in the POS program, and the invoice will normally have a 0 balance.
• An AR Payment or “check” record is created for the Cash Payment or refund. The AR Payment record is assigned a Type of “P” (POS Payment) and a Trancode of “PCS” (POS Cash). The AR Payment record is assigned a unique number that is based on the #ARTRAN counter, and it is assigned a unique comment number – so that notes can be attached to the record if required. The AR Payment record stores the name of the customer associated with the payment or refund, and the cash amount received or paid out. The AR Payment record is assigned to the POS Cash Clearing Account. The payment record is used to verify the daily deposit and paid out totals,and it is also used during AR Deposit processing.
• A Journal Entry is made for the Cash Payment or Refund. The journal entry lines are assigned a source of PS (POS), and a Code of PCS (POS Cash). The line that posts the payment to the POS Cash Clearing Account stores the unique #ARTRAN that was assigned to the AR Payment record in the Memo field of the JE line. The journal entry line that posts the payment to the AR Control Account stores the unique AR Payment number in the Memo field of the JE Line, and the invoice number that the payment was applied to in the Ref No field of the JE Line.
Check
- je is created for cash payment amount, and ar, Post to POS Clearing (cks, credit cards) autopost 1002 - we need to deposit these after verifying totals. We currently create ar check record for each ck payment. Trancode CHK is written to code field in je. ck# into memo field of je We may want to add diff type for the pos checks - so we can filter them out of std ck lookup or display in dedicated program, and add the artran# to indexes - so we dont end up with dupes or continue to have to adj ck numbers (ie the -1, -2 trick in normal pmt processing or you putting the tran after the pos cks). Deposit process creates bank record for use in bank rec.
- another option here would be to skip the ar check record for pos checks and just generate the bank record - for bank rec purposes - at this point we would only have the customer (based on invoice), the ck# (recorded in the je line) and date, operator, station where it was received - this would avoid a ton of records for cash sale customer ......we would have only the je detail to back up total ck deposits (we could also again store some info in the bank rec to allow showing proper je detail if we need to look at it).
downside on the no ar check approach would be customer who buys both wholesale and thru pos - we could look up some cks but not others when they have questions.
regardless - I would still suggest adding artran# to indexes to solve original problem on "normal" customer pmts - and to make consistent with other acctg data - which has unique internal id.
Credit Card
- je is created for credit card pmt amt, ar. Post to POS Clearing autopost 1002. - We have cctran record pointed to by memo field in the je line for the clearing acct. Trancode CC is written to code field in je. ref# in ar line points to invoice. Deposit creates bank record for use in bank rec, deposit process also allows recording cc fees imposed by cc gateway, processor - - if we updated the cc tran records with the deposit or bank number we use, we would also have ability to go back and see the cc details for each deposit based on cc tran file (gets us similar to what we get from having the ar check detail). - same if we used the je detail (to be consistent - so all deposit processing is based on je detail) we can still get to cc tran detail from there and arent duplicating the cc tran info in an ar check record.
Issue gift cert (this is a trade or "sale" and pmt in one)
Cash or POS Clearing (debit) - depending on type of pmt received - 1001, 1002
Gift Certificates (credit) - for amt of the negative invoice (this ends up being separate subledger - so you dont intermingle with other ar )
- we dont show sale until gc is redeemed. - issue cert causes us to show liability - represented by a negative ar invoice.
Cash or credit card, check 100 (1001, 1002)
Gift Certificates 100 (1005 - new autopost to show gift cert outstanding)
- we probably need a separate issue gift cert button (it creates invoice with line item that posts to gift cert acct, vs ar - or we post direct to gl accts - like non inventory invoice.) idea again is we dont show revenue here until the gift cert is redeemed.
Redeem gift cert (payment method).
- we apply the gift cert invoice record to the open balance on the new invoice. Amt of GC being applied is posted as debit to gift cert autopost, credit to ar. additional line created for any change issued out (if policy is to give change). we could write the gc autopost to the gift cert "invoice" record so we know to post that invoice to 1005 - invoice type could also be used to flag how to post, and keep it from showing up on existing ar agings).
Gift cert 100 (1005?)
AR 80 (120 - 129)
Cash 20(1001)
or we create indiv je for each - to be consistent - so each adj to ar and assoc pmt or credit is separate je by itself - may make deposit logic easier - but we have separate cash line in either case.
Gift Cert 100
AR 100
AR 20
Cash 20
Apply Store Credit (I am treating this as pmt method vs refund since it is similar to redeeming a gift cert).
je line for store credit apply has code ASC or SCA (apply store credit)
AR 100 store credit being used) - ref# in je ties to store credit inv# (120-129)
AR 100 (new invoice being paid) (120-129) invoice# in ref# field, SCA in memo
store credit has no effect on deposit processing but needs to show as separate line on end of day report so we can ensure we have the copy of doc and can check invoice is closed out for proper amt
can be partial or full pmt (similar logic applies to gift cert )
the store credit could also be partially used, or additional pmt could be received.
If partial, we just leave the remaining amt of store credit invoice open
if additonal pmt is received, we add another two je lines for the pmt - tied to the new invoice.
(120 purchase, 100 gift cert, 20 cash received)
AR 100 (store credit) (120-129)
AR 100 (new invoice) (120-129)
Cash 20 (additional cash pmt) (1001 or 1002 if check or credit card)
AR 20 (balance of new invoice being paid) (120-129)
Exchange
- we need to be able to handle a net zero tran (customer returns one item - back to stock, we give them replacement ) - this could be done on one invoice
Coupons??????
- NO bank records are needed for gift cert, store credit, exchange or coupons as they are not going into or coming out of bank acct
Refund Processing
Cash
- allow negative payment amount - flag as refund at je level to allow breakout during end of day reporting, reconciliation. (cash line would be a credit instead of debit), code in je is still CSH (or could be CSR - if amt is negative to help us flag line during reporting )
AR 100 (120-129) - ref# points to invoice, memo = CASH
POS Cash 100 (1001) memo=CASH
negative amts are included in the bank deposit amt - we show net when moving cash from cash box to bank acct
Credit Card Refund - credit against negative invoice balance.
AR 100 (120-129) je line code CCR, je tied to invoice in ref#, could also tie to cc tran in memo
POS Clearing 100 (1002) je line code is CCR (cc refund) - je MEMO tied to cctran - same logic as when pmt processed
either separate bank record or included in bank record for cc totals for shift, day, company, - depends on how it shows up on the bank stmt.
Issue Store Credit
- create negative invoice balance tied to customer, original invoice (using original invoice field in 56 )- need new invoice source (PSC) - to allow filtering , blocking apply to normal invoices for same customer
Sales (plus cos, tax, etc) 20
AR 20
AR Refund check ?
- allow refund pmt against negative invoice - like existing ar refund off of ar invoice lookup. This creates a bank record for bank rec already.
AR 100 (autopost 120-129) (close out the open store credit invoice)
Cash 100 (100-119) - actual cash acct issued from - since we are writing a ck.
open - if we allow trading credit or gift cert for cash without sale also taking place.