Inventory Planning Report

Upload attachments somewhere and provide link here. Check MySQL / apache error logs for hints.

Hello, just to clarify how the algorithm works.

In the report /reporting/rep302.php (Inventory Planning Report), line 175.

First the maximum of the last 4 months is calculated.
Then this maximum is multiplied with 3 to get a 3 months estimate.

This is based on known methods to eliminate the risk for one-time selling.

However, if you feel this is not good for you, then please give me a good argument to change this.

/Joe

Joe, I am ok with the calculation, I just can't figure out why some sales appear on the report and some do not.

Hi, this is my first post, although I have been using FA for a few years now. Absolutely outstanding system. Seahawk's post was about my system when I asked him to try and solve it, and I see Randr has the same problem.
Only in Inventory Planning Report the monthly unit sales is 0 for about 25% of the stock items. The average monthly sales is thus also 0, although it shows the correct QOH, Supp Ord and Cust Ord. The Sugg Ord is then also not correct.
The correct unit sales are available from inventory movements, but it is quite a job to extract everything manually. The other reports seem to be all OK.
Some of the older DOS programs had a "rebuild indexes" option which solved this type of problem, or am I going in the wrong direction?

Hi, I'm working on @BigFunHappens's system and is trying to solve the same problem as what seahawk enquired about.

Here is an example of the problem: https://imgur.com/a/LBIxjKN

The image shows an example of the inventory planning report as is shown in our system.
The values inside of the red border are incorrect.

Many items function as intended like the 1st item in the example report, but some items have the same problem as the 2nd item.

I have tried to access the MySQL logs but it seems as if we cannot view the logs with our current web host package. Could this be true?

You can still insert file write statements to spit out the inspection points / variable values. Read the Wiki.

Inventory Planning Report is reporting/rep302.php.

@joe: Lines 50 and 52 can be removed in reporting/rep302.php as there can be only one description for one id for both category_id and stock_id fields.

Also Line 77  filters on ST_CUSTCREDIT (11) and ST_CUSTDELIVERY (13) instead of on ST_SUPPRECEIVE (25) and ST_CUSTDELIVERY (13) and the need to take care of transactions pertaining to ST_MANUISSUE (28) and ST_MANURECEIVE (29) with the signs being taken care of as well.

Further, lines 38 and 39:

            IF(move.stock_id IS NULL, '', move.loc_code) AS loc_code,
            SUM(IF(move.stock_id IS NULL, 0, move.qty)) AS qty_on_hand

can be re-coded as

            COALESCE(move.loc_code, '') AS loc_code,
            SUM(COALESCE(move.qty, 0)) AS qty_on_hand

rep302.php is the Inventory Planning Report.

There are only 2 main SQLs in it in the functions:

getTransactions()
getPeriods()

Do some single stepping and check the value of the $sql variable in them and see if the tables need any (non primary key) indexes to speed it up.

Hope you have the following Unique Indexes:

`stock_category`.`description`
`stock_master`.`description`

The former is there in my default install and the latter may need to be inculcated.

How many transactions are you querying and hope your PHP.ini file has adequate memory allocated.

@joe: Adding an Unique Index for `stock_master`.`description` may be in order.

Brother It looks like the description and long description affects and also the no of query which runs for this report is huge.

@Joe we need to find an alternative  way for it.