One Step Retail Solutions Community Forums
Home      Members   Calendar   Who's On
Welcome Guest ( Login | Register )
      

Home » One Step Data » General discusion » Retail News » Core Updates 9/16/04


Core Updates 9/16/04Expand / Collapse
Author
Message
Posted 9/24/2004 2:59:01 PM


Forum Member

Forum MemberForum MemberForum MemberForum MemberForum MemberForum MemberForum MemberForum Member

Group: Forum Members
Last Login: 5/27/2005 1:56:00 PM
Posts: 103, Visits: 1

The September Core Updates for versions 8.51, 8.4, and 7.63 are now available on the OSD Downloads site.

http://downloads.onestepdata.com

All current OSD clients can access this site with their user name and password. If you have forgotten them, e-mail support@onestepdata.com to have them sent to your system administrator.



Post #782
Posted 9/25/2004 12:05:05 PM


Forum Guru

Forum GuruForum GuruForum GuruForum GuruForum GuruForum GuruForum GuruForum Guru

Group: Forum Members
Last Login: 9/11/2007 9:00:44 AM
Posts: 1,461, Visits: 933
We will post the contents of the core update on Monday.


Thanks for using the forums!

 

Dan Jablons

Also visit kb.onestepdata.com for our Fantastic Knowledge Base!

Post #787
Posted 9/27/2004 8:55:04 AM


Forum Member

Forum MemberForum MemberForum MemberForum MemberForum MemberForum MemberForum MemberForum Member

Group: Forum Members
Last Login: 5/27/2005 1:56:00 PM
Posts: 103, Visits: 1

   Partner Services

Briefing

  September, 21st 2004

 

 

 

Retail Pro BTF-Series7.63/8.4/8.5

Update Release Cycle

 

RPro v8.51 Core  

Updated executables Contained in the August RPro v8.51 Core update:

Core Files:

Rpro8.exe, Rpro_Api.bpl, RDA2.dll, RproBroker.exe, RproBrokerSvc.exe, exchange.exe, ms_ie_d5.bpl, RPRO_API.bpl, vcl50.bpl, vclie50.bpl, ITResolution.exe, TranUpdate.exe, exchange.exe, Intranfix.exe

 

Tools:

 Auto.exe,  mprocin.exe,  rprocout.exe,


Issue ID: 

14312

WebTAC ID:

27238

Area:

Polling

Severity:

1 - Critical

Title: 

Regen Updating Company SO's multiple times.

Description: 

BP/Customer:BHD/Contemporary Concepts - 5343

 

Reported Problem:

When Regen is run any receipts that were part of company so's will again update the QTY Sent field. Steps to reproduce.

 

1.) Create a Company SO at the main.

2.) Poll this SO to the remote.

3.) Create a Receipt for the SO, selling all items.

4.) Poll the receipt to the main.

5.) Check the SO's QTY sent fields for proper amounts sold.

6.) Regen all history files at the remote, Proc out then repoll with main.

7.) Look at the SO notice all QTY sent fields have doubled. You can affect this field every time you regen, so QTY sent fields may double or even triple.

 

BHD also suggested implementing a tool that would recalculate this field. This would not only fix this issue but other issues where this may be wrong on a SO. It would be much like the Rebuild Rcvd QTY tool.

 

Resolution:

Regerating history files at a Remote caused quantities on Sales Orders with receipts polled to Main to be incremented every time regenerate is run.  The Sales Order was being processed every time the Receipt was received.  Now Sales Orders are only processed when the Receipt is new.

 

Issue ID: 

14305

WebTAC ID:

 

Area:

Polling

Severity:

3 - Moderate

Title: 

Deactivated Employee Sales Targets are always polled

Description: 

I can deactivate a Subsidiary/Store sales target in EMS.  Communicate it to RPro Main. 

 

There is no filter from the remote side of polling that prevents deactivated employee sales targets from being polled up to the mains.

Resolution:

In previous versions of RPro,  there was no filter in polling to prevent de-activated employee sales targets from being sent.  This meant that target polling files could grow extremely large.  Now when processing sales target only the active sales targets are sent.

 

Issue ID: 

14294

WebTAC ID:

27219

Area:

Receipts

Severity:

2 - Serious

Title: 

Select Appropriate Item box does not sort items correctly on Item #

Description: 

BP/Customer:

EL Korea

 

Reported Problem:

Add three items to Inventory use ALU 123B for the first item, 123A for the second item and 123C for the third item.  Now on a receipt enter 123 into the item# field.  You will receive the Select Appropriate Item box with all three items list so you can select the correct item.  Notice that they are sorted by ALU even though the sort arrow is on the Item# field.  You can change to ALU and back to Item# and the items will still be sorted by ALU and not Item#.

 

System Impact:

This is causing confusion with the clerks at POS.  EL's inventory is entered in such a manner that they should always use the lowest item#.  So this should be the first item in the list but it is not since the sort is by ALU.  So they are enter the wrong items onto receipts.

Resolution:

A new system preference has been added called "Sort lookup items by Item#" under General Documents.  If checked, it will cause item lookup to always sort by item number.

 

Issue ID: 

14289

WebTAC ID:

 

Area:

Sales Orders

Severity:

2 - Serious

Title: 

PLUGINS: Adding an (SO) item from a plugin sometimes leads to multiple empty rows in the items grid.

Description: 

This scenario has two plugin classes, a TSidebutton plugin and a TItemsAddRemove plugin.

The TSidePlugin operates on SOs and when it is executed it adds an item to the SO.

The TItemAddRemove Plugin also operates on SOs. if the TItemAddRemove.BeforeAdd method returns false to Retail Pro (dissalow Retail Pro from adding the item), the new empty line will sometimes remain in the grid. When the plugins are all done there will be two empty lines in the items grid.

 

This happens when the sidebutton is clicked before the user has clicked in the items grid.

If you click in the items grid first, regardless of whether you add any items or subsequently move the cursor to another field outside the items grid Retail Pro will execute correctly and there will be no extra emty lines.

 

Attached compiled test plugin with source code.

Resolution:

If conditions are such so that no additional items can be added to the RPro inventory, the plug in call, TSidePlugin, was causing two empty lines in the items grid to be added. Document recalculation has been enforced after an item had been rejected by plugin - that updates the number of available slots on the document and eliminate the addition of the extra rows.

 

Issue ID: 

14240

WebTAC ID:

26579, 26683, 28058, 28085,

Area:

Auto Utilities

Severity:

3 - Moderate

Title: 

Single store merchant edition installs do not have a "stores" list in the :CALC area of auto MIN MAX and you get an error trying to execute formula

Description: 

BP/Customer:

CDS/Yippee Yi Yo - 2389

Reported Problem:

 

Create a single store merchant edition

Go into the AUTO

create a formula

go into CALC.

Notice there is no "stores "column

If you attempt to run the formula you get an error "No formulas apply to the selected stores. " It appears as though there is no internal default store selected in the tool.

Resolution:

Fixed the issue where Min/Max values could not be calculated in a single store merchant edition.

 

Issue ID: 

14233

WebTAC ID:

14078, 27789

Area:

Tools - Scheduler

Severity:

2 - Serious

Title: 

Scheduling INTRANFIX and ITRESOLUTION does not correct mismatched pairs

Description: 

Scheduling INTRANFIX and ITRESOLUTION does not correct mismatched pairs existing in the TransVerification area.

When done manually in the TransVerification, pressing RESOLVE ALL does correct mismatched pairs based on predefined resolution instructions established in syspref.  Everything works fine.  However, when scheduling this process to occur automatically, it does not work.

To recreate:

1) establish your resolution instructions.  I used the following: any store to any store, qty = 5, adjust the source location

2) create an outslip transferring an item from 000 to 001 (qty= 10, Days in transit = 2)

3) create a mismatched inslip transferring the same item from 000 to 001 (qty = 9 this time)

4) Schedule 3 tasks to run ITRESOLUTION.exe (no parameters except to specify your workstation number), run INTRANFIX.exe (no parameters except to specify your workstation number) and TRANUPDATE.exe (no parameters except to specify your workstation number).

5) manually RUN NOW each task back-to-back.

****ITRESOLUTION and INTRANFIX should fix the mismatched pair based on your instructions in sys pref.  In this case, the outslip is reversed and a new outslip is created with quantity of 9.  It does not do this.  When done manually via the TransVerification area, pressing RESOLVE ALL does.

****Another issue to address is that when scheduling INTRANFIX, you get a popup window that asks you to press START followed by another that asks you to press OK. There are no documented parameters to bypss these windows.  I have been told by SQA and Design that parameters do not exist for these TransVerification programs.

Resolution:

Note From Alexey:

VERY IMPORTANT: INTRANFIX is not supposed to be scheduled. It's a one-time fixing tool which is only applicable to some older versions of PROC tools and older versions of 7-series remotes working with 8-series mains. What it does is it is updating number of days in-transit and removing TargetUpdate flag on unmarked unverified slips (it is needed if you upgrade from 7-series to 8-series and need to pickup your existing unverified slips correctly). Since in 8-series it is perfectly valid to have UNMARKED unverified slip with TargetUpdate flag been set the INTRANFIX tool should NOT be used on a regular basis, or it will allow the target inventory to be updated several times.

 

Fix Notes:

The problem was primarily with workstation setup - INTRAN tools were designed to work with workstation 111. If INTRAN tools cannot determine workstation number they revert to using WS111, which implies two limitations:

a) workstation-specific slip counters do not exist, so slips will be created with system-wide document numbering;

b) history path is not specified, so all slip files are assumed to be located in the RPRO folder.

 

 

Issue ID: 

14229

WebTAC ID:

26196

Area:

Polling

Severity:

3 - Moderate

Title: 

Regenerating receipts from the remote to the main or sending differences from the main to the remote is dropping gift card transactions

Description: 

BP/Customer:

Rob @ BHD/Made In Oregon

 

Reported Problem:

Regenerating receipts from the remote to the main or sending differences from the main to the remote is dropping gift card transactions.

Steps to reproduce:

> Set up a remote and a main.

> Setup PPM as you gift card type at the remote.

> At the remote create a receipt, go to tender and create 5 gift card transaction on the receipt.

> Now poll the receipt from the remote to the main.  Note that the receipt has all the gift card transaction on it.

> Now either send differences from the main to the remote or regenerate receipts from the remote to the main.  Once you have processed in at the main or the rem