Jump to content


- - - - -

PROFIT


10 replies to this topic

#1 Guest_USWCI_*

Guest_USWCI_*
  • Guests

Posted 23 September 2003 - 06:08 AM

We are a large chain of retail stores and currently using PROFIT for our merchandising/ inventory system. I am writing to seek help regarding the abnormal system behavior we are experiencing with the software.

Our stores are connected at the Head Office where the system resides via WAN. Our system configuration are as follows :

IBM J50 AIX 4.2.1
PRO-IV 5.2.8
PROFIT 3.2 Release 3
Database : C-ISAM and PRO-ISAM


CASES :

1. Two skus/items from the same Transaction Receipt No. were posted in the Stock Movement File on two different dates.

EXAMPLE :

In this particular case, the Receipt transaction was updated on 07/23/2003 but the Stock Movement Inquiry shows that (1) item was posted the following day.

Take note that, this is not an issue of partial delivery as we do not allow such.

Change MRSRECNQ
07/25/03 RECEIPT INQUIRY 000/ATL/PTS_65

Receiving Store< 008 EDSA CROSSING WAREHOUSE
Receipt Date : 07/23/03 Receipt No.< 80816

Receipt Document Date
Line Date Recpt# Type No. Status Updated Dsc Itms
---- -------- ------- ----------- ---------- ---------------- -------- === ====
0001 07/23/03 80816 PURCH ORDER 086005426/0UPDATED 07/23/03


Lookup IMSSMINQ
07/25/03 Stock Movement Inquiry 000/ATL/PTS_65

Short SKU< 33145 BAGUIO PECHAY
Store < 008 EDSA CROSSING WAREHOUSE Type : R Receipts
From Date: 04/21/2003 To Date: 07/25/2003 Print:
<--- Ref ---> <- On Hand -->
LINE Store UpdtDate UTime Type Number Quantity Quantity F/T Store
++++ ----- ---------- ----- ----- ------- ----------- -------------- ---------
00001 008 07/23/2003 12:52 Recpt 80816 50.00 437.50-



Lookup IMSSMINQ
07/25/03 Stock Movement Inquiry 000/ATL/PTS_65

Short SKU< 43670 EGGPLANT
Store < 008 EDSA CROSSING WAREHOUSE Type : R Receipts
From Date: 04/21/2003 To Date: 07/25/2003 Print:
<--- Ref ---> <- On Hand -->
LINE Store UpdtDate UTime Type Number Quantity Quantity F/T Store
++++ ----- ---------- ----- ----- ------- ----------- -------------- ---------
00002 008 07/24/2003 14:24 Recpt 80816 68.30 7955.43-



2. Transaction was posted repeatedly.

EXAMPLE :

In this particular example, the transfer note contains only one sku but posted 4 times in the Stock Movement File.


Lookup IMSSMINQ
07/25/03 Stock Movement Inquiry 000/ATL/PTS_65

Short SKU< 3090855 06xGUH-088 UN75/1 1.75X4 SHOE BRUSH
Store < 007 LAS PI√ĎAS WHSE Type : X Transfers
From Date: 04/21/2003 To Date: 07/25/2003 Print:
<--- Ref ---> <- On Hand -->
LINE Store UpdtDate UTime Type Number Quantity Quantity F/T Store
++++ ----- ---------- ----- ----- ------- ----------- -------------- ---------
00003 007 05/18/2003 09:32 Xfer 4167 500.00- 996.00 013
00004 007 05/18/2003 08:08 Xfer 4167 500.00- 1496.00 013
00005 007 05/18/2003 07:27 Xfer 4167 500.00- 1996.00 013
00006 007 05/18/2003 07:25 Xfer 4167 500.00- 2496.00 013

#2 Chris Mackenzie

Chris Mackenzie

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 368 posts
  • Gender:Male
  • Location:Bristol, United Kingdom

Posted 23 September 2003 - 08:14 AM

Hi,

Do these problems occur all the time or sporadically?

Well, I'm guessing but I don't think anyone will
be able to solve this without spending time
actually looking at the system.

Have you checked for file corruptions in your system
using ischeck (proisam) and bcheck (cisam)?

Also my guess is you do not have any support for
this application from the supplier? If so then it
sounds like you will need to do something
about that at the hurry-up...
The content and views expressed in this message are those
of the poster and do not represent those of any organisation.

#3 cplau

cplau

    Newbie

  • Members
  • Pip
  • 4 posts
  • Gender:Male

Posted 23 September 2003 - 03:38 PM

Hi,

For your case 1:
Did you check the Last Day Updated in Control File? Would it be possible that
dates in certain files are updated using system date (@DATE) and some of them in
other files are updated using Last Day Updated.
If some one has run the End of day until the 07/26/2003, then your Last Day
Updated will be stamped as 07/25/2003.

Regards,

CP

#4 Shaun Rudland

Shaun Rudland

    Expert

  • Members
  • PipPipPipPip
  • 165 posts
  • Location:Queensland, Australia

Posted 24 September 2003 - 12:51 AM

Chris is perfectly correct. Profit is a complicated system, and if anyone can solve specific intermittent transactional errors remotely then I will be surprised. In addition to the inherent complexity, all the installations of Profit I was involved in were significantly customised for the end customer. Therefore if your application has been tailored to your particular needs it would be extremely difficult for any entity to diagnose and correct errors without source code access. If you have local on-site support available, it may be worthwhile in investing in it.

In the meantime, if your version of Profit is a generic one, then it may be an installation issue. If this is the case one thing to consider is Terminal IDs. Profit work files are keyed by Terminal ID, therefore any duplicate IDs among users will cause "strange" errors. Are the IDs unique across the user base ?
PRO-IV free for 385 Days B)

#5 Guest_USWCI_*

Guest_USWCI_*
  • Guests

Posted 24 September 2003 - 10:49 AM

Thanks for your remarks!

Those cases happen sporadically. Actually, we have already referred these problems to our PROFIT vendor (QR Malaysia) and they simply reasoned out that C-ISAM and PRO-ISAM has no rollback feature that manages the saving of transactions consistently.

#6 Rob Donovan

Rob Donovan

    rob@proivrc.com

  • Admin
  • 1,640 posts
  • Gender:Male
  • Location:Spain

Posted 24 September 2003 - 11:13 AM

C-ISAM and PRO-ISAM has no rollback feature that manages the saving of transactions consistently


True, they dont have Rollbacks, but your system should be able to be changed to fix the problem.

The problem is, to find where its going wrong, since its does not seem to happen very frequently. :rolleyes:

There are lots of systems out there that use ProISAM / CISAM successfully.

Rob D.

#7 Guest_USWCI_*

Guest_USWCI_*
  • Guests

Posted 25 September 2003 - 09:49 AM

The problem is, to find where its going wrong, since its does not seem to happen very frequently. :rolleyes:

Rob D.


The problem is, we cannot establish the pattern as to when it occurs. When we reviewed the transaction, it seemed perfectly maintained by the user.

#8 Guest_Guest_*

Guest_Guest_*
  • Guests

Posted 25 September 2003 - 09:51 AM

Have you checked for file corruptions in your system
using ischeck (proisam) and bcheck (cisam)?


We have already checked every single file using ISCHECK for pro-isam and BCHECK for C-Isam and we did'nt find any corrupted file.

#9 Chris Mackenzie

Chris Mackenzie

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 368 posts
  • Gender:Male
  • Location:Bristol, United Kingdom

Posted 25 September 2003 - 12:33 PM

Hi,

Seems like you really need your supplier to spend more
time on this. But I have one more suggestion that you
have probably already thought of: are your users reliable?

Might they have experienced an error message and not
reported it? Something like 'Error writing file: CONTROL'
perhaps. Or they may have just missed it... maybe the
read of the control number was ok and the write of the
transaction was ok but the write back of the control
number failed (without seeing the code I don't know if
this is feasible) - do you ever run out of disk space?
Or someone may have manually reset
the number somehow (or the flag that controls whether
the repeating transaction is processed yet).

There must be lots of possibilities but
"PROFIT vendor (QR Malaysia) [...] simply reasoned out that C-ISAM and PRO-ISAM has no rollback feature that manages the saving of transactions consistently." is not good enough.


luck.
The content and views expressed in this message are those
of the poster and do not represent those of any organisation.

#10 Guest_Guest_*

Guest_Guest_*
  • Guests

Posted 25 September 2003 - 12:57 PM

As Chris rightly says,

they simply reasoned out that C-ISAM and PRO-ISAM has no rollback feature that manages the saving of transactions consistently

simply isn't good enough.

An application that relied on rollback for correct processing would be a very unusual PRO-IV application and if your application does then why on earth has your vendor allowed it to be deployed on a platform that doesn't support rollback?!

#11 Guest_Guest_*

Guest_Guest_*
  • Guests

Posted 26 September 2003 - 09:19 AM

Hi,

For your case 1:
Did you check the Last Day Updated in Control File? Would it be possible that
dates in certain files are updated using system date (@DATE) and some of them in
other files are updated using Last Day Updated.
If some one has run the End of day until the 07/26/2003, then your Last Day
Updated will be stamped as 07/25/2003.

Regards,

CP


True that our programs consistently use (Last Day Updated + 1) for current day transactions but I'm quite confident that no one has mistakenly run the End of Day because if that was the case, more problems/implications could have come out on that same day. But there were no problems reported other than that.

Thanks!



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users