JDE Point of Sale

nkuebelbeck

nkuebelbeck

VIP Member
Anyone out there roll their own POS inside jde using standard tools(BSFN,FORMS,UBE,BI PUB)? Not interested in out-of-box solutions. (I know about all of them, I have Google too!)

Project came up for cash to sale similar to a typical POS. This would be for stock items, pay with either cash,check,credit card at time of order.

My biggest question is the sales receipt. Should this be a receipt for unapplied cash, sales invoice, other?
 
We had a division that has since closed and had a POS system.

We used sales order entry along with subsystem procesing to generate the sales order receipt (customized R42565). The order entry would be 520/580, subsystem advanced to 580/620. We had customized the screens to pop-up payment method and saved information in a custom table that was used later at EOD processing for daily deposit [reconciliation purposes]. It wasn't pretty as the screens are a bit clunky in JDE for point of sale but it was working although it did require a fair amount of customization to add payment screen, calculate taxes for totals, subsystem printing was a little flakey (may be better now?), and custom app for deposits.

We also took in payments on account and had customized AR receipts to accept method of payment (again saving in custom table for deposits) and then add call to custom app for AR receipt printing with method of payment, invoices paid and customer information.
 
We had a division that has since closed and had a POS system.

We used sales order entry along with subsystem procesing to generate the sales order receipt (customized R42565). The order entry would be 520/580, subsystem advanced to 580/620. We had customized the screens to pop-up payment method and saved information in a custom table that was used later at EOD processing for daily deposit [reconciliation purposes]. It wasn't pretty as the screens are a bit clunky in JDE for point of sale but it was working although it did require a fair amount of customization to add payment screen, calculate taxes for totals, subsystem printing was a little flakey (may be better now?), and custom app for deposits.

We also took in payments on account and had customized AR receipts to accept method of payment (again saving in custom table for deposits) and then add call to custom app for AR receipt printing with method of payment, invoices paid and customer information.

Thanks for the feedback! Did you use the stock P4210 for input?
 
Is there a way to open a program's form in ADD mode from a different interactive program? *cough P4210.W4210A* I've done the call to F4211FSBeginDoc but I want the P4210.W4210A to do my heavy lifting.
 
If you don't pass a sales order# (and other primary keys), it should automatically open in ADD mode when called form any interactive app.
 
If you don't pass a sales order# (and other primary keys), it should automatically open in ADD mode when called form any interactive app.

Thanks for the response. If I do that, then none of the other parameters (FI Variables) seem to stick. (I know my soldto/shipto before hand, this is my I was trying to call begin doc before opening that form)
 
Thanks for the response. If I do that, then none of the other parameters (FI Variables) seem to stick. (I know my soldto/shipto before hand, this is my I was trying to call begin doc before opening that form)

There is a parm in the begin doc, whether or not to use a work file (cCMUpdateWriteToWF ), I had to change that value to 2 when executing the begin doc, and pass that value to the form interconnect P4210.W4210A -> UpdatedToHdrWF and then it worked.

Now P4210 can do all the heavy lifting of validating sales order lines.
 
I've seen POS done in JDE at a few sites and none of them have been very pretty or efficient from an end user perspective. One site did a mixture of over the counter sales either on account or as cash sales. All of the sales orders were processed through to invoiced at the time of the transaction and then at the end of the day the tills were loaded in as unapplied cash which was then matched up to all of the invoices for the cash sales customer. Reconciliation between the tills and JDE was always fun. The only reason they kept JDE as the POS system was the volume was fairly low and most of the sales were on account with fairly complicated advanced pricing schedules.
 
We had a division that has since closed and had a POS system.

We used sales order entry along with subsystem procesing to generate the sales order receipt (customized R42565). The order entry would be 520/580, subsystem advanced to 580/620. We had customized the screens to pop-up payment method and saved information in a custom table that was used later at EOD processing for daily deposit [reconciliation purposes]. It wasn't pretty as the screens are a bit clunky in JDE for point of sale but it was working although it did require a fair amount of customization to add payment screen, calculate taxes for totals, subsystem printing was a little flakey (may be better now?), and custom app for deposits.

We also took in payments on account and had customized AR receipts to accept method of payment (again saving in custom table for deposits) and then add call to custom app for AR receipt printing with method of payment, invoices paid and customer information.

Did you ever have to deal with returns and cash?
 
Yes we did. We entered the negative quantity in P4210 and had our customization of P4210 be able to handle the negative cash/visa/debit plus we also had our custom deposit program handle the negative as well...subtracting from daily method-of-payment totals.
We had a few issues like if there was a slow day at a branch and only one method of payment being the return so the negative amount would not work (ie cash float) We just had them wait until next day for more sales so that the deopsit amount would not be negative.

As to the end user perspective it was a little slow but was MUCH cheaper than purchasing a full system *AND* having to deal with connectivity, customization and interchange between the two systems. Plus being able to control POS to our desires was nice!
We are somewhat undergoing that now with another package system integrating with JDE.

We did our payments using the AR receipts program and yeah just customized that a little and had our customer program for deposit interact with the payments tables (F03b13 & F03b14 I think?).

** We did not change the working of P4210 but only really added on to existing functionality by calling some updates and display screen to capture some information after data was entered.
 
Yes we did. We entered the negative quantity in P4210 and had our customization of P4210 be able to handle the negative cash/visa/debit plus we also had our custom deposit program handle the negative as well...subtracting from daily method-of-payment totals.
We had a few issues like if there was a slow day at a branch and only one method of payment being the return so the negative amount would not work (ie cash float) We just had them wait until next day for more sales so that the deopsit amount would not be negative.

As to the end user perspective it was a little slow but was MUCH cheaper than purchasing a full system *AND* having to deal with connectivity, customization and interchange between the two systems. Plus being able to control POS to our desires was nice!
We are somewhat undergoing that now with another package system integrating with JDE.

We did our payments using the AR receipts program and yeah just customized that a little and had our customer program for deposit interact with the payments tables (F03b13 & F03b14 I think?).

** We did not change the working of P4210 but only really added on to existing functionality by calling some updates and display screen to capture some information after data was entered.

Thanks for the response.

I've got the whole thing working just not with credit orders yet. working through that now. Using Auto Cash (Doc ID 1458442.1)to make receipts from prepayments table F004201(Custom UBE to insert into F03B13Z1) and using subsystem processing (R03B551 & R03B50) to match receipts to invoices.
 
Back
Top