POS Check Payment Processing

Point of Sale (POS) > Point of Sale Overview > POS Payment Processing

POS Check Payment Processing

This section describes how to process a Check Payment using the POS program.

Once you have entered the items being sold to or returned by the customer and press the Pay Button in the POS program, the POS Payment Panel is displayed.

A check payment can be entered in the POS Payment Panel by pressing the check button using the touchscreen or mouse. Once the Check Button is pressed, the system displays the following prompt.

The customer check number, the check amount and an optional comment should be entered into the appropriate fields. Once the check information has been entered, and the Ok Button has been pressed, the system displays the payment in the top section of the POS Payment Panel.

POS Check Payment – Transaction Details

- 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.

POS Credit Card Payment Processing

POS Credit Card Payment – Transaction Details

- 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.

POS Giftcard Processing