Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Core Updates 9/16/04
#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.
Reply
#2
We will post the contents of the core update on Monday.
Reply
#3

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 remote you will notice that this receipt now only has 3 gift card transaction on it.

System Impact:

Serious

Resolution:

Guft Card Transactions are lost from a receipt after regenerating receipts at a remote and polling to the MAIN. In other words, at a remote, regenerating a previously polled receipt with 5 gift card transactions will result in some of the gift card transactions getting lost at the main. Now, no gift card transactions are lost after regerating and polling again.

Issue ID:

14171

WebTAC ID:

26000

Area:

Polling

Severity:

2 - Serious

Title:

Exchange file transfer window does not run minimized

Description:

BP/Customer:

RTI/ISC

Reported Problem:

Exchange file transfer window does not run minimized whether it is run from scheduler with the designation of "run minimized" or run from trans with show details "unchecked"

To replicate

create a main and a remote and then setup Internet polling

run exchange from a scheduled task at the remote station and set it to run minimized. Note that when exchange takes place the exchange window runs minimized but that when the files begin to get transferred a window comes up displaying the file transfer status.

System Impact:

Very large for this client. They are polling registers that are setup as stations frequently throughout the day while POS is in use for transactions. The transfer window is interfering with the users making transactions.

Resolution:

The file transfer windows during Exchange did not run in a minimized state when run from a command line with Scheduler, even if the 'Run Minimized' option is selected in Scheduler. Now there is an additional parameter (/M or -M) when running exchange from a command line. NOTE: When running exchange from 8.40 and below, it is still required that the 'Run Minimized' option is selected. This is not required for 8.50 and above, but will do no harm.

Issue ID:

14162

WebTAC ID:

25551

Area:

General System

Severity:

2 - Serious

Title:

Proposed POs not available at shop edition remotes

Description:

BP/Customer:

Reported Problem:

According to documented specifications remote POs should be available at a Shop edition remote.

Source of documentation

http://partners.retailpro.com/Sales/sale...arison.pdf

To replicate:

1> Create a shop main and initialize a remote 001a.

2> Turn on allow this remote to propose POs in system preferences.

3> go into RPROdb

4> go into purchasing. Right click on the menu bar to the right. Notice that the proposed PO button is not available. You cannot add the button.

System Impact:

User cannot propose POs

Resolution:

Proposed POs could not be created at a Shop edition remote. The 'Proposed PO' button could not be added to the menu, and in System Preferences, the checkbox to enalbe the ability to Propse POs was always grayed out at a remote. Now the checkbox in System Preferences and the Button are availabe, and it is possible to Propose POs.

Issue ID:

14113

WebTAC ID:

26733

Area:

Customers

Severity:

3 - Moderate

Title:

There is no warning when you enter a invalid zip code. There was in V7.63.

Description:

BP/Customer: LVNA

Reported Problem:

In V7.63 if you were using the Zip code masking to enter the city, state you would receive a warning that the zip code did not exist if you entered an invalid zip code. This warning is gone in V8. You can enter any zip and it does not tell you it is invalid.

System Impact:

Clerks can create a new customer with an invalid zip code and then they do not have a city or state.

Resolution:

In 7.63, a warning was displayed if an invalid Zip Code was entered if Preferences were set to do Zip Cose Lookup. There was no such message in 8-Series. An error message was added, so now entering an invaid Zip Code will cause a warning message to display.

Issue ID:

14078

WebTAC ID:

25290, 14233, 25588

Area:

Slips

Severity:

2 - Serious

Title:

Itresolve.exe will not resolve all

Description:

BP/Customer:In house

Reported Problem:

I created a rule to match out slip to in slip when there is a qty diff below 10. I then created an out slip with qty 1 of an item, and also made an in slip but with a qty of 2. Then in Trans verification I selected resolve all, this resolved the slips. I did the same setup but did not resolve in Trans verification, instead I used Itresolve.exe. The result of this did not resolve the slips.

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:

13966

WebTAC ID:

24099

Area:

Inventory

Severity:

3 - Moderate

Title:

ALU does not print leading 0 (zero) when the ALU is 13 chars

Description:

14392

BP/Customer:

Principle/PRI

Reported Problem:

1>Create a line of inventory with an ALU that is 13 characters long *(make the first character a zero) EX. 0123456789012

2>Select Print Notice the the 0 does not print

3>Add a digit to the end of the ALU 01234567890123 and print Note the 0 prints

If you put any other character in position 0 it does print, and if you have any other length of ALU a leading zero will print. The bug only occurs on 13 character ALUs where the 0 is at the beginning of the string.

System Impact:

Problem for correctly identifying Items on printed documents as this problem occurs on document printouts such as Slips as well.

Resolution:

If the ALU for an item has 13 characters with a leading zero (0), the leading zero was dropped when printing that item on a document or from Inventory. Now the leading zero is no longer dropped.

Issue ID:

13752

WebTAC ID:

Area:

General System

Severity:

2 - Serious

Title:

Plugins: Nested documents, reading IRdaDocument.Get{Type} can give a different result than IRdaDocument.IRdaField.Value

Description:

Logged for "Area: Receipts" but true for all documents that have nested items.

If a plugin is reading information about an item in a nested document it can get different information depending on wether it reads information using the IRdaDocumen.Get{type} methods or the IRdaField.

IRdaField reads the currently highlighted item, IRdaDocument.Get... reads the last edited/added item.

To reproduce:

Create a TSideButton plugin with the following code in the "Execute" method:

function TSBBugTest.Execute: TActionRequestSet;

var

wbIsNull: WordBool;

begin

ShowMessage ('Desc 1:' + #13#10

+ 'IRdaField: ' + fItem.FieldByID(fidDesc1).Text + #13#10

+ 'GetString: ' + fItem.GetString (fidDesc1, wbIsNull));

Result := [arRefreshDocument];

end;

(note this plugin has been attached to this bug.)

Create a new receipts and add several items.

click (once) on the first item (do not put the item in edit mode).

Click the plugin button. it will display:

Desc 1:

IRdaField: Description of first Item

GetString: Description of last item

sometimes the last item is a blank line at the bottom in which case the GetString will get no information at all.

click again in for example the qty field of the first item to set the item in edit mode.

click the plugin side button again, it will now display:

Desc 1:

IRdaField: Description of first Item

GetString: Description of first Item

In most plugins this can be worked around by always reading information using the IRdaField object; however, when you need to use the TRProApp.DisplayItem (to drive a pole display) it needs to get information using the IRdaDocumet.Get{type} methods and will thus display incorrect information.

Attachment is a compiled test plugin using the code above.

Resolution:

The values returned for IRdaDocument.Get{Type} and IRdaDocument.IRdaField.Value often gave different results due to data objects not being synchronized. This caused difficulties with plugins. This was especially visible in the plugins that drove pole display. To correct this issue, three new calls were added to the IRdaDocument interface for plugins. These calls are:

function DesyncDetected: WordBool; safecall;

procedure ResyncPosition;safecall;

procedure ResyncToLastSetPosition;

DesyncDetected returns a boolean value(True) if the position of the data object is not synchronized.

The second fuction ResyncPosition synchronizes the internal position to the UI position.

ResyncToLastSetPosition synchronizes the UI position to internal position

Apply Caution When Using these Calls:

1) never call ResyncPosition or ResyncToLastSetPosition in the ItemBeforeAdd event;

2) call to ResyncToLastSetPosition can lead to recalculation of number of items on a document, so use it very carefully inside the loops which iterate through list of items - number of items (i.e. IRdaDocument.Count) can suddenly change if current position is moved off new item record before item number is assigned;

3) call to ResyncToLastSetPosition leads to UI being updated, so it invokes quite a few notifications passed inside of Rpro core and it can negatively affect performance of your plugin - only use it when absolutely necessary (same comment about excessive use is also applicable to ResyncPosition call).

Issue ID:

13733

WebTAC ID:

22676

Area:

Vouchers

Severity:

3 - Moderate

Title:

Price and Cost values on new Styles are from last new style.

Description:

1. Create a new Voucher

2. Go to Choose/Edit Items

3. Create a style (form view) with 3 items with Doc Price and Cost.

4. Notice the Price and Cost is populated with the same values as the document price and cost.

Return to the Voucher.

5. Go back to Choose/Edit Items.

6. Create another Style, but look at the Doc.Price and Doc.Cost. They are the same values as the previous item.

7. If the style is saved without modifying the price and cost fields the values will be zero.

Resolution:

When creating a new style within a voucher the document price and cost fields were being populated with incorrect values. This was caused by the data buffers not clearing properly. This issue has been fixed.

Issue ID:

13716

WebTAC ID:

13978, 14353, 22720, 26422, 221

Area:

Tools - Doc Designer

Severity:

5 - Change Request

Title:

Doc Designer> Printing Grids on designs

Description:

If you are printing information in a grid format there is no way to prevent the printing of a grid if it doesn't fit on one page.

The major problem occurs when you look at the information on the second page (the second half of the grid) it does not display the DCS, VC, DESC1, etc... about the items in the grid.

This particular issue is very bothersome to JDA's client Michelsons.

Resolution:

When printing information in a grid format, the grid header information did not repeat when the grid itself spanned more than one page. As a result, it is difficult to read and analyze grids. The header information now repeats at the top of the grid if the grid gets split because of page breaks.

Issue ID:

13674

WebTAC ID:

22430

Area:

Vouchers

Severity:

2 - Serious

Title:

Voucher Tax incl % rounds to nearest whole number

Description:

Create a voucher and add an item to the voucher.

On the voucher form add the TAX incl.% using page designer

On the context menu to right add the TAX incl % button to the menu through menu designer.

Try to add a tax percentage of 1.5%. It will be rounded up. It should not round at all.

This is a significant issue for this client as their tax percentages for items purchased on vouchers are 4.2% 8.4% and 12.6%

Hi-Style (12034)/Radesh/IRMC

Resolution:

Corrected the issue where Voucher Tax Incl % was rounding to nearest whole number when entered. Now decimal values can be entered.

Issue ID:

13499

WebTAC ID:

22062, 22218

Area:

Polling

Severity:

3 - Moderate

Title:

SO deleted at the Remote is causing error in Polling

Description:

BP/Customer:

OSD / Shabby Chic

Reported Problem:

Create an SO at a remote and poll it up to the Main and poll back to the remote. The SO is in the Mains SO file and everything is fine. Now at the remote, complete the deposit and record the sale. Delete the SO and select to Archive the SO. Now poll back to the Main.

At the Main, there is no record of the SO in either the Active file nor the Archived file. The receipts are in the Mains history file.

There is a Critical error in the polling log that states (example) " Unable to Update Invoice #0001 for SO #002A0000000004 for Store #002A". After polling back to the remote, the SO is still in the Archived file, but never makes it to the Main.

System Impact:

Client needs to have these Archived SO's at the Main and is very suspect of their data because of the Critical error in polling.

Resolution:

The error message in the procin log showed a critical error when a Sales Order that has been deleted and archived at a remote is sent back to the main. There is no longer an error message displayed in the log.


Rpro v8.40 Core

Updated executables Contained in the August Rpro v8.40 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, Intranfix.exe

Tools:

Auto.exe, RproPI.exe, mprocin.exe, rprocout.exe, cprocout.exe, exchange.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:

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 remote you will notice that this receipt now only has 3 gift card transaction on it.

System Impact:

Serious

Resolution:

Guft Card Transactions are lost from a receipt after regenerating receipts at a remote and polling to the MAIN. In other words, at a remote, regenerating a previously polled receipt with 5 gift card transactions will result in some of the gift card transactions getting lost at the main. Now, no gift card transactions are lost after regerating and polling again.

Issue ID:

14171

WebTAC ID:

26000

Area:

Polling

Severity:

2 - Serious

Title:

Exchange file transfer window does not run minimized

Description:

BP/Customer:

RTI/ISC

Reported Problem:

Exchange file transfer window does not run minimized whether it is run from scheduler with the designation of "run minimized" or run from trans with show details "unchecked"

To replicate

create a main and a remote and then setup Internet polling

run exchange from a scheduled task at the remote station and set it to run minimized. Note that when exchange takes place the exchange window runs minimized but that when the files begin to get transferred a window comes up displaying the file transfer status.

System Impact:

Very large for this client. They are polling registers that are setup as stations frequently throughout the day while POS is in use for transactions. The transfer window is interfering with the users making transactions.

Resolution:

The file transfer windows during Exchange did not run in a minimized state when run from a command line with Scheduler, even if the 'Run Minimized' option is selected in Scheduler. Now there is an additional parameter (/M or -M) when running exchange from a command line. NOTE: When running exchange from 8.40 and below, it is still required that the 'Run Minimized' option is selected. This is not required for 8.50 and above, but will do no harm.

Issue ID:

14162

WebTAC ID:

25551

Area:

General System

Severity:

2 - Serious

Title:

Proposed POs not available at shop edition remotes

Description:

BP/Customer:

Reported Problem:

According to documented specifications remote POs should be available at a Shop edition remote.

Source of documentation

http://partners.retailpro.com/Sales/sale...arison.pdf

To replicate:

1> Create a shop main and initialize a remote 001a.

2> Turn on allow this remote to propose POs in system preferences.

3> go into RPROdb

4> go into purchasing. Right click on the menu bar to the right. Notice that the proposed PO button is not available. You cannot add the button.

System Impact:

User cannot propose POs

Resolution:

Proposed POs could not be created at a Shop edition remote. The 'Proposed PO' button could not be added to the menu, and in System Preferences, the checkbox to enalbe the ability to Propse POs was always grayed out at a remote. Now the checkbox in System Preferences and the Button are availabe, and it is possible to Propose POs.

Issue ID:

14078

WebTAC ID:

25290, 14233, 25588

Area:

Slips

Severity:

2 - Serious

Title:

Itresolve.exe will not resolve all

Description:

BP/Customer:In house

Reported Problem:

I created a rule to match out slip to in slip when there is a qty diff below 10. I then created an out slip with qty 1 of an item, and also made an in slip but with a qty of 2. Then in Trans verification I selected resolve all, this resolved the slips. I did the same setup but did not resolve in Trans verification, instead I used Itresolve.exe. The result of this did not resolve the slips.

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:

13752

WebTAC ID:

Area:

General System

Severity:

2 - Serious

Title:

Plugins: Nested documents, reading IRdaDocument.Get{Type} can give a different result than IRdaDocument.IRdaField.Value

Description:

Logged for "Area: Receipts" but true for all documents that have nested items.

If a plugin is reading information about an item in a nested document it can get different information depending on wether it reads information using the IRdaDocumen.Get{type} methods or the IRdaField.

IRdaField reads the currently highlighted item, IRdaDocument.Get... reads the last edited/added item.

To reproduce:

Create a TSideButton plugin with the following code in the "Execute" method:

function TSBBugTest.Execute: TActionRequestSet;

var

wbIsNull: WordBool;

begin

ShowMessage ('Desc 1:' + #13#10

+ 'IRdaField: ' + fItem.FieldByID(fidDesc1).Text + #13#10

+ 'GetString: ' + fItem.GetString (fidDesc1, wbIsNull));

Result := [arRefreshDocument];

end;

(note this plugin has been attached to this bug.)

Create a new receipts and add several items.

click (once) on the first item (do not put the item in edit mode).

Click the plugin button. it will display:

Desc 1:

IRdaField: Description of first Item

GetString: Description of last item

sometimes the last item is a blank line at the bottom in which case the GetString will get no information at all.

click again in for example the qty field of the first item to set the item in edit mode.

click the plugin side button again, it will now display:

Desc 1:

IRdaField: Description of first Item

GetString: Description of first Item

In most plugins this can be worked around by always reading information using the IRdaField object; however, when you need to use the TRProApp.DisplayItem (to drive a pole display) it needs to get information using the IRdaDocumet.Get{type} methods and will thus display incorrect information.

Attachment is a compiled test plugin using the code above.

Resolution:

The values returned for IRdaDocument.Get{Type} and IRdaDocument.IRdaField.Value often gave different results due to data objects not being synchronized. This caused difficulties with plugins. This was especially visible in the plugins that drove pole display. To correct this issue, three new calls were added to the IRdaDocument interface for plugins. These calls are:

function DesyncDetected: WordBool; safecall;

procedure ResyncPosition;safecall;

procedure ResyncToLastSetPosition;

DesyncDetected returns a boolean value(True) if the position of the data object is not synchronized.

The second fuction ResyncPosition synchronizes the internal position to the UI position.

ResyncToLastSetPosition synchronizes the UI position to internal position

Apply Caution When Using these Calls:

1) never call ResyncPosition or ResyncToLastSetPosition in the ItemBeforeAdd event;

2) call to ResyncToLastSetPosition can lead to recalculation of number of items on a document, so use it very carefully inside the loops which iterate through list of items - number of items (i.e. IRdaDocument.Count) can suddenly change if current position is moved off new item record before item number is assigned;

3) call to ResyncToLastSetPosition leads to UI being updated, so it invokes quite a few notifications passed inside of Rpro core and it can negatively affect performance of your plugin - only use it when absolutely necessary (same comment about excessive use is also applicable to ResyncPosition call).

Issue ID:

13674

WebTAC ID:

22430

Area:

Vouchers

Severity:

2 - Serious

Title:

Voucher Tax incl % rounds to nearest whole number

Description:

Create a voucher and add an item to the voucher.

On the voucher form add the TAX incl.% using page designer

On the context menu to right add the TAX incl % button to the menu through menu designer.

Try to add a tax percentage of 1.5%. It will be rounded up. It should not round at all.

This is a significant issue for this client as their tax percentages for items purchased on vouchers are 4.2% 8.4% and 12.6%

Hi-Style (12034)/Radesh/IRMC

Resolution:

Corrected the issue where Voucher Tax Incl % was rounding to nearest whole number when entered. Now decimal values can be entered.

Issue ID:

13575

WebTAC ID:

14247, 21779, 23702, 22024

Area:

Receipts

Severity:

2 - Serious

Title:

Package items are not listing the correct price on receipts.

Description:

Steps to reproduce:

Go to system preferences and set up quantity based pricing in POS > price/discount.

Create an item in inventory with a price of $2.30.

Then create a package and add 10 of this item to the package with a price of $22.99 for price level 1.

For price level 2 make the price 21.99 with a quantity of 3 for the package.

Create a receipt and go to choose edit items and select the package and click on "ok".

Then increase the quantity on the package to 3.

You will notice that the price on the items in the package has increased to $6.60. If you change the quantity of the packages back to one the price on the items will now be $0.77.

Found by: Jerret @ STG

Client: The Rez

Resolution:

Rpro will now calculate the quantity based pricing correctly on package items in Receipts.

Issue ID:

13499

WebTAC ID:

22062, 22218

Area:

Polling

Severity:

3 - Moderate

Title:

SO deleted at the Remote is causing error in Polling

Description:

BP/Customer:

OSD / Shabby Chic

Reported Problem:

Create an SO at a remote and poll it up to the Main and poll back to the remote. The SO is in the Mains SO file and everything is fine. Now at the remote, complete the deposit and record the sale. Delete the SO and select to Archive the SO. Now poll back to the Main.

At the Main, there is no record of the SO in either the Active file nor the Archived file. The receipts are in the Mains history file.

There is a Critical error in the polling log that states (example) " Unable to Update Invoice #0001 for SO #002A0000000004 for Store #002A". After polling back to the remote, the SO is still in the Archived file, but never makes it to the Main.

System Impact:

Client needs to have these Archived SO's at the Main and is very suspect of their data because of the Critical error in polling.

Resolution:

The error message in the procin log showed a critical error when a Sales Order that has been deleted and archived at a remote is sent back to the main. There is no longer an error message displayed in the log.


Rpro v7.63 Core

Updated executables Contained in the July Rpro v7.63 Core update:

Core Files:

Activity.exe, Activity.rez, advops.exe

Tools:

Auto.exe, mprocin.exe, rprocout.exe, cprocout.exe, exchange.exe

Issue ID:

14391

WebTAC ID:

14299

Area:

Receipts

Severity:

3 - Moderate

Title:

Cannot change tax code in F5 window

Description:

In the latest activity.exe file that was released to Hershey Park for the track1/track2 issue, they cannot change the tax code in the F5 window of an invoice and have that change take affect on the doc. You can change the code itself but it does not update the doc. In the 8.10.04 it works correctly.

Resolution:

The tax code was being processed before going into the f5 function, on return it was not being returned to the item. It is now fixed

Issue ID:

14299

WebTAC ID:

26481, 14391

Area:

Receipts

Severity:

1 - Critical

Title:

PPM transactions that contain Track 1 and Track 2 card swipes are causing a large number of Declines

Description:

BP/Customer:

IMS/Hershey

Reported Problem:

Hershey Park receives a large number of declines when authorizing some cards that have track 1 and track 2 data in the swipe. This problem has been reportedly corrected by BPS through the use of MSRs that are programmed to read only track 2. Please change activity to include a switch to read only track one when passing swipes to dll that hands it off to Paymentech.

System Impact:

Preventing the roll out of PPM /

Resolution:

Added a switch to allow reading of only track 1 information

Issue ID:

14171

WebTAC ID:

26000

Area:

Polling

Severity:

2 - Serious

Title:

Exchange file transfer window does not run minimized

Description:

BP/Customer:

RTI/ISC

Reported Problem:

Exchange file transfer window does not run minimized whether it is run from scheduler with the designation of "run minimized" or run from trans with show details "unchecked"

To replicate

create a main and a remote and then setup Internet polling

run exchange from a scheduled task at the remote station and set it to run minimized. Note that when exchange takes place the exchange window runs minimized but that when the files begin to get transferred a window comes up displaying the file transfer status.

System Impact:

Very large for this client. They are polling registers that are setup as stations frequently throughout the day while POS is in use for transactions. The transfer window is interfering with the users making transactions.

Resolution:

The file transfer windows during Exchange did not run in a minimized state when run from a command line with Scheduler, even if the 'Run Minimized' option is selected in Scheduler. Now there is an additional parameter (/M or -M) when running exchange from a command line. NOTE: When running exchange from 8.40 and below, it is still required that the 'Run Minimized' option is selected. This is not required for 8.50 and above, but will do no harm.

Issue ID:

13539

WebTAC ID:

Area:

Slips

Severity:

4 - Low

Title:

Slips headers have incorrect number of records if extended item information is used

Description:

Create an inventory item with extended information (desc3/4, or ALU, or Aux fields) which can eb stored in slip extended item record. Then create a slip with that item. Run reconstruct in test mode - it will complain with something similar to this:

==========================

1/15/2004 1:24:53 PM: *** Slip header (RecNo=5282) has incorrect item counts

1/15/2004 1:24:53 PM: Suggestions:

1/15/2004 1:24:53 PM: Set slip headers item counts to actual counts

==========================

The reason for this error is that slips have a field which stores total number of records in this document, and it does not count extended item records. It seems to have no negative impact on business logic, but nevertheless reconstruct finds this bug and complains about it. It [reconstruct] can fix it, but the origin of the bug is in 7-series.

Resolution:

The correct number of records are now reported in the slip document header.

Issue ID:

13466

WebTAC ID:

21370

Area:

Adjustment Memos

Severity:

3 - Moderate

Title:

Items on a quantity adjustment memo with a quantity of 0 are not saved when you select new items.

Description:

Steps to reproduce:

Create a quantitiy adjustment memo.

enter some items by item number and set any new qty except 0

enter some items by item number and set the new qty to 0

hit the alt key and choose to enter items by select option

enter some qty's for some items and esc back to the document.

It will not save the items that were entered by item number and set to a 0 qty.

Resolution:

Items on an Adjustment memo with 0 quantity will remain on the memo when adding more items using the Select Items screen.


Multi-Version Tools



Auto


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.


Procs


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:

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 remote you will notice that this receipt now only has 3 gift card transaction on it.

System Impact:

Serious

Resolution:

Guft Card Transactions are lost from a receipt after regenerating receipts at a remote and polling to the MAIN. In other words, at a remote, regenerating a previously polled receipt with 5 gift card transactions will result in some of the gift card transactions getting lost at the main. Now, no gift card transactions are lost after regerating and polling again.

Issue ID:

13499

WebTAC ID:

22062, 22218

Area:

Polling

Severity:

3 - Moderate

Title:

SO deleted at the Remote is causing error in Polling

Description:

BP/Customer:

OSD / Shabby Chic

Reported Problem:

Create an SO at a remote and poll it up to the Main and poll back to the remote. The SO is in the Mains SO file and everything is fine. Now at the remote, complete the deposit and record the sale. Delete the SO and select to Archive the SO. Now poll back to the Main.

At the Main, there is no record of the SO in either the Active file nor the Archived file. The receipts are in the Mains history file.

There is a Critical error in the polling log that states (example) " Unable to Update Invoice #0001 for SO #002A0000000004 for Store #002A". After polling back to the remote, the SO is still in the Archived file, but never makes it to the Main.

System Impact:

Client needs to have these Archived SO's at the Main and is very suspect of their data because of the Critical error in polling.

Resolution:

The error message in the procin log showed a critical error when a Sales Order that has been deleted and archived at a remote is sent back to the main. There is no longer an error message displayed in the log.


Exchange 7.63 & 8.40


Issue ID:

14171

WebTAC ID:

26000

Area:

Polling

Severity:

2 - Serious

Title:

Exchange file transfer window does not run minimized

Description:

BP/Customer:

RTI/ISC

Reported Problem:

Exchange file transfer window does not run minimized whether it is run from scheduler with the designation of "run minimized" or run from trans with show details "unchecked"

To replicate

create a main and a remote and then setup Internet polling

run exchange from a scheduled task at the remote station and set it to run minimized. Note that when exchange takes place the exchange window runs minimized but that when the files begin to get transferred a window comes up displaying the file transfer status.

System Impact:

Very large for this client. They are polling registers that are setup as stations frequently throughout the day while POS is in use for transactions. The transfer window is interfering with the users making transactions.

Resolution:

The file transfer windows during Exchange did not run in a minimized state when run from a command line with Scheduler, even if the 'Run Minimized' option is selected in Scheduler. Now there is an additional parameter (/M or -M) when running exchange from a command line. NOTE: When running exchange from 8.40 and below, it is still required that the 'Run Minimized' option is selected. This is not required for 8.50 and above, but will do no harm.


ECI

Updated Files:

ExtPresetRcptPrint.bpl, GiftReceipt.bpl, CLoyalty.bpl


Issue ID:

14012

WebTAC ID:

24778

Area:

Merchandiser

Severity:

3 - Moderate

Title:

ECI > item rows that are removed in clean house and reused retain the "exclude from web" check mark

Description:

BP/Customer:

Don @ OSD/Leo's Department Store

Reported Problem:

If you clean house on an item and reuse the row it will retain the exclude from web switch that the previous item had.

Steps to reproduce:

>Create a new item in Rpro, and add the item to a catalog in ECI.

>Mark this new item "exclude from web" in ECI.

>Now go into Clean house and delete this item you created

>You should note that the item was also deleted from the ECI catalog when you cleaned house on this item.

>Using the same row as the item you just deleted (in clean house) add a new item.

>Then go add this new item to the ECI catalog. You will notice that the item when added to the catalog will be marked "exclude from web" where it should default to unmarked.

System Impact:

Adding items to the catalog requires an additional step to verify the item is added to the web site.

Resolution:

If an item is removed in clean house the exclude from web flag is set. However, previously if that item was re-used the flag was retained. A change was made so when an item is added to the catalog the flag would be cleared.


Issue ID:

13766

WebTAC ID:

23110

Area:

Merchandiser

Severity:

4 - Low

Title:

ECI Reports>Catalog documents fail to report inventory AUX fields.

Description:

BP/Customerne Step Data/Liz Lange Maternity

Reported Problem:

In Doc designer when editing documents in the ECCatalog schema. After adding Inventory AUX fields to the design, the ECI Reports>Catalog documents fail to report the value of the inventory AUX fields.

Resolution:

When creating a report with Auxiliary fields for ECI not all of the fields would display. This was caused by improper labeling of fields within the ECI Catalog schema. The Schema has been updated to not only correct the style level auxiliary fields but to add the item level auxialiary fields.

_________________________________________________________________________

-----------------------------------------------------------------------------

Reply
#4
PERFECT!

Finally, we all know what is happening in the updates!

(plus I can update my min/max now)!
Reply
#5
will there be an easy way to install these updates, like an auto update i can place on cds and send out to stores?

i have a lot of stores and it isnt easy getting all theses updates done in a timely fashion.

i've been working on creating an executable w/ winzip, but even that can easily fail.
Reply
#6
8.4 installations can always use the RPRO Update feature. The store would need to have high speed internet access to use it effectively.

Otherwise, mailing each store the updates on CDs and co-ordinating an update is the best way I know of. Since the updates are getting close to 90 megs in version 8, polling them over isn't practical anymore.

Maybe someone else has a better idea.
Reply
#7
If a change is made in Rpro.exe. When I do an rproupdate, it will download the entire .exe correct.

Why can't RTI/IP code up a updater that just downloads and inserts ONLY THE CHANGES MADE . Every virus scan software that I know of updates its virus database list.

This would make downloads extremely small I would think.

I can't imagine that with each update the dev's are rewriting more than 1% of the code. So a 90 MEG update would shrink to 90KB downloads.

just my 2 platinums

-twgJR
Reply
#8
The to update a system they would have to do all the updates in sequential order. Most users don't have a need for an update every month. Most don't ever need an update. But, when you find yourself in that need, the full update is necessary.
Reply
#9
virus definition updates update basically a text database, and when there is an executable update it downloads the whole executable, wich usually is only 4 mb, i believe NAV is 4 megs and NOD32 is somewhere around 1MB, i dont know what macafee is, cant stand thier product.
Reply
#10
OK, time for me to chime in.

Virus databases are NOT AT ALL THE SAME as an application. And while it is true that McAfee (or Norton, or any of them) send small updates to the database, when they have to update their engine (main program) they send THE WHOLE THING.

So the idea of not sending the whole thing is simply not possible.

The answer, of course, is high speed internet access so you can get the updates in short order without too much downtime.

Sorry, but that's just the way it is....
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)