| | | Forum Newbie
       
Group: Forum Members Last Login: 3/14/2005 3:17:00 PM Posts: 3, Visits: 1 |
| Retail Pro BTF-Series 8.4/8.5/Tools Update Release Cycle Updated executables Contained in the February RPro v8.51 Core update: Core Files: Rpro8.exe, ms_ie_d5.bpl, vclie50.bpl, vcl50.bpl, RPRO_API.bpl, rda2.dll, RPro8.sec, RProDB.exe, RproDB.sec, SecAdmin.exe, PPMSERVR.exe, RtiShift4Gift.dll, RtiShift4Debit.dll, RtiShift4Credit.dll, RtiShift4Check.dll, RtiGift.dll, RtiDebit.dll, RtiCredit.dll, RtiCheck.dll, ReceiptRTISchema.xml, CustHistoryRTISchema.xml | | Tools: SLCC.exe
Issue ID: | 14883 | WebTAC ID: | | Area: | Vouchers | Severity: | 3 - Moderate | Title: | Copying a voucher from a closed period to an open period does not clear the Audit flag | Description: | When copying a voucher from a closed period to an open period, the Audit flag is not cleared. This process is needed in order to work around a current design limitation of Stock Audit. Once copied, the document should be editable. | Resolution: | Issue: Copying a voucher from a closed period to an open period does not clear the Audit flag Solution: The Audit flag is cleared on all documents (receipts, vouchers, memos and slips) when they are copied. |
Issue ID: | 14840 | WebTAC ID: | 31016 | Area: | EFT - General | Severity: | 1 - Critical | Title: | EFT settings return to DEFAULT value of NONE when connection is lost | Description: | Reported Problem: Create an installation of RPRO with a mapped drive to an EFT folder where PPM or CPRO is running. Setup workstation prefs to use the correct Credit option under EFT Make a transaction to confirm the modem is dialing etc. Disconnect the mapped drive Exit out of RPRO Run the instance of RPRO again and go into another EFT transaction NOTE the prompt for EFT card type comes up. Go into workstation preferences EFT>Credit. Note it is now set to NONE. | Resolution: | Whenever a user goes to the tender screen, access to the eft folder is checked. If the folder cannot be accessed for any reason, or if there is a problem loading the eft files when first going into the tender screen, an error message is displayed and the eft tender buttons are disabled. The same logic was also put into SO's. The cashier can complete the transaction using a different type of tender. |
Issue ID: | 14833 | WebTAC ID: | | Area: | Security Manager | Severity: | 2 - Serious | Title: | Communicating De-activated employees to RPro 8 causes Access Violations | Description: | An access violation can be generated when an employee that is a member of an RPro 8 Group is deactivated in V. 9 and communicated back to V. 8 Create an employee in RPro 9 and communicate the employee to RPro 8. Once in RPro 8 add this employee to a group. Process back to V. 9 and de-activate the employee. Communicate the change back to V. 8 After Processing in the changes go to SecAdmin > Groups in V. 8 and Open a group (different from the group that you assigned the now de-activated employee to) and add another employee to the group and save. An Access Violation is shown at this point. | Resolution: | Initial Problem: An access violation is created when deactivating employees in RPro 9 and communicating the change back to RPro 8. Solution: SecAdmin library was modified to detect when ECM has deleted employees and read data from RtiSec.dat on the fly. |
Issue ID: | 14803 | WebTAC ID: | 30257 | Area: | EFT - Shift4 | Severity: | 2 - Serious | Title: | Shift4 credit card transactions duplicating under certain conditions | Description: | Reported Problem: Based on analysis of trace files from customer combined with the audit trail sent to Shift4 from the client Shift4 has determined that Retail Pro is ignoring responses from Shift4 after an auth has been sent. This in turn causes them to time out and as such is a root cause of a duplicated transaction. Additional information: When the user tries to authorize again after the timeout, RPro doesn’t always use the same transaction number. We should use the same transaction number again, so we don’t defeat Shift4’s duplicate checking code. | Resolution: | Programming has changed the way transaction numbers are assigned. There's a file in the eft folder called shift4sn.dat which holds the serial numbers that are used to as transaction numbers. There used to just be one serial number that was shared by all workstations, but now each workstation has it's own serial number. Each serial number is in the range 1 to 999999. The transaction number consists of a 2 digit workstation number followed by the serial number for that workstation. Only if the transaction is approved is the serial number incremented. On the receipt tender screen, the transaction number is displayed in the reference number field (as before). |
Issue ID: | 14794 | WebTAC ID: | | Area: | Stock Audit | Severity: | 1 - Critical | Title: | Stock Audit not creating open balances when choose to start from RPro backup all qtys zero | Description: | Stock Audit is not creating opening balances if you choose to start from a Retail Pro backup, all quantities are zero. 1) Make a backup of Retail Pro 2) Start SLCC and choose to create opening balance from a backup 3) Point the directory to the Retail\Rpro directoy for the backup 4) once step (3) is done start a new period 5) check the openeing balnce it will equal zero. | Resolution: | Issue: When using a data back up to create an initial open period within stock audit the inventory cost and quantities were zero. Solution: Stock Audit has been fixed so that when and opening period is created from a snapshot of inventory the opening cost and company quantity is updated. |
Issue ID: | 14780 | WebTAC ID: | 30736 | Area: | EFT - PPM | Severity: | 3 - Moderate | Title: | PPMserver Times out dialog during upload of large batch | Description: | Reported Problem: The time out put in place for the credit card dialog is timing out before PPMserver is done uploading the batch. This is causing the dialog to give the error "time out" while PPMserver is still posting the batch. See attached log. Steps to replicate. Select upload You will see Connected then see Settling batch ### after about a minute you get Timed out click OK Queued at the server message is displayed for about a minute until the cancel button can be hit, Brings you back to the the Upload screen If you try to settle again you get no batches to settle System Impact: The user will be confused by this. | Resolution: | The PPMServer will now stay open until the batch is finished processing. No timeout errors should be reported. |
Issue ID: | 14768 | WebTAC ID: | 30735 | Area: | EFT - PPM | Severity: | 2 - Serious | Title: | Duplicate checking in PPM creates a possible problem with void transactions | Description: | Reported Problem: 1> Create a transaction with a credit card and authorize it. 2> Now before updating the transaction void the authorizations by deleting the authorized amount in the tender window. 3> Now rerun the same amount using the same card and exp date etc. Note you get the "duplicate authorization" prompt. The options are to use the existing authorization or create a new authorization. If you choose to use the existing authorization the system does not go out and get a good authorization. It simply keeps the voided one that is in the batch. This is bad for the client as it is confusing to the cashiers at POS. What happens is the cashier not knowing can select to use the previous auth and create a situation where the receipt can still be updated. One of three things should happen: A> if the user chooses to use the existing authorization IE keep the void, then the tender should not be applied as a positive or B> the duplicate checking should not offer to use the existing transaction when it is a voided transaction. or C> as the duplicate issue has been corrected through disabling the cancel button and managing the way PPMserver behaves when using predial , rem out the routine for duplicate checking all together | Resolution: | Voided authorization information is now not stored. This prevents the situation in the issue description from occurring. |
Issue ID: | 14694 | WebTAC ID: | 29840, 30820 | Area: | Sales Orders | Severity: | 1 - Critical | Title: | SO deposit created when not tendered. | Description: | Reported Problem: With A Deposit amount required on an SO a user can back out of an SO deposit and cause a receipt to be made. Steps to Reproduce. 1.) System Preferences > Require a 10 % deposit on SO's. 2.) Make a SO then Save, The user will be propted to leave a deposit. 3.) In the Deposit Screen do not tender and just select Back from the side menu. 4.) Back in the SO Screen Select Save again and the user will once again be brought to the Deposit screen and a new deposit will have been started. 5.) Once again in the Deposit Screen do not tender and just select Back from the side menu. 6.) Again back in the SO Screen Select Save again and the user will once again be brought to the Deposit screen and another new deposit will have been started. 7.) Do not tender and select the second deposit row with your mouse. 8.) Select the RPRO buttion in the upper corner. This will back you out to the Retail pro home screen, with out a deposit being made. 9.) Now check former SO's there will have been a SO made. And in former receipts there will be a deposit receipt for the so tendered using store credit. | Resolution: | The deposit on an SO isn't removed when the back button is pressed while in the deposit screen. This would result in a customer receiving unearned store credit in certain situations. Now the deposit is removed if the back button is selected prior to tendering the deposit. |
Issue ID: | 14844 | WebTAC ID: | 31051 | Area: | EFT | Severity: | 2 - Serious | Title: | POSres takes more than a minute to determine there is no connection to NETAPI | Description: | Reported Problem: Due to the limitation in windows that results in NetAPI reporting a valid connection to POSres RPRO takes more than a minute to go into offline eft mode when the router side network connection is lost. Please add a configurable timeout value to an ini file. The time out should not be used if there is no value in INI file variable. IE if the value for time out is not set POSres should determine connectivity normally otherwise if the the timeout value is present then use that value to determine that the connection has been lost. | Resolution: | Added a section and a key to rtishift4.ini which is located in the eft folder: [System] OnlineCheckTimeoutSeconds=15 Part of the fix for this bug was put into 8.51 and 8.40 even though they don't support POS Resiliency. If netapi is shut down in the middle of running a transaction, RPro would wait indefinitely for a response from netapi. Now, the user will get an unexpected disconnect error message soon after netapi is shut down. |
| |
Updated executables Contained in the February RPro v8.40 Core update: Core Files: Rpro8.exe, vclie50.bpl, vcl50.bpl, RPRO_API.bpl, rda2.dll, RPro8.sec, SecAdmin.exe, PPMSERVR.exe, RtiShift4Debit.dll, RtiShift4Credit.dll, RtiShift4Check.dll, RtiDebit.dll, RtiCredit.dll, RtiCheck.dll | | Tools: SLCC.exe
Issue ID: | 14833 | WebTAC ID: | | Area: | Security Manager | Severity: | 2 - Serious | Title: | Communicating De-activated employees to RPro 8 causes Access Violations | Description: | An access violation can be generated when an employee that is a member of an RPro 8 Group is deactivated in V. 9 and communicated back to V. 8 Create an employee in RPro 9 and communicate the employee to RPro 8. Once in RPro 8 add this employee to a group. Process back to V. 9 and de-activate the employee. Communicate the change back to V. 8 After Processing in the changes go to SecAdmin > Groups in V. 8 and Open a group (different from the group that you assigned the now de-activated employee to) and add another employee to the group and save. An Access Violation is shown at this point. Found Internally by Alexey | Resolution: | Initial Problem: An access violation is created when deactivating employees in RPro 9 and communicating the change back to RPro 8. Solution: SecAdmin library was modified to detect when ECM has deleted employees and read data from RtiSec.dat on the fly. |
Issue ID: | 14803 | WebTAC ID: | 30257 | Area: | EFT - Shift4 | Severity: | 2 - Serious | Title: | Shift4 credit card transactions duplicating under certain conditions | Description: | Reported Problem: Based on analysis of trace files from customer combined with the audit trail sent to Shift4 from the client Shift4 has determined that Retail Pro is ignoring responses from Shift4 after an auth has been sent. This in turn causes them to time out and as such is a root cause of a duplicated transaction. Additional information: When the user tries to authorize again after the timeout, RPro doesn’t always use the same transaction number. We should use the same transaction number again, so we don’t defeat Shift4’s duplicate checking code. | Resolution: | |
|
|
| |
|