Re: 41/IN & integrity reports

Craig_Potter

Craig_Potter

Reputable Poster
Re: 41/IN & integrity reports

See "A:'s" below...


Now the Q is :
1. Confirmation of the above

A: Confirmed

2. If no doc types are included in 41/IN, then system will use rule 3. In
this case for any doc type how does the system understand which DMAAI table
to look at. Will it look at all the DMAAI tables in rule3, AND wherever it
finds a matching combination of CO & GL CLASS, it will select all such
relevant object accounts, and then go on to F0911 ??

A: Sort of. It builds a list of valid Object Accounts from all the AAI's
for the rule. Then it reads the F0911 and ignores entries that are not
hitting these accounts when calculating the 'Account Ledger' value.

In that case there is always the possibility of it locating more than one
object a/c for the CO + GL Class combination.

A: Correct. When this occurs you will find entries on the R41543 report
with an Account Ledger = 0 or not easily reconciled. The workaround is to
change the 41/IN entry for that document type to a different rule. Of
course, depending on your AAI setup this workaround will not always work.
There are many SAR's around this problem both putting Doc type logic in and
then taking it out again. Most sites who experience these problems have
given up and either modified this logic or written their own integrity
programs.

2. Does it need to be set up for all user defined doc types or only for
user defined sales order/invoice, PV's i.e. Rule 1 & 2 related documents
only.

A: It only needs to be setup for those document types not suited to rule 3
(see above)

3. We would like to run the following reports on a regular basis as
scheduler jobs. Can anyone direct me if there is anything specifi!
c order in which these should be run. Given below is the order that we
propose :
- R31802 for all orders with status =95, (R31804 may be run later after
researching variances
- R09800 for posting all open batches
- R41542
- R41548
- R41544
- R41543

A: Sequence looks OK, although note that R41548 is an annual job to build
new fiscal year opening balances in the As-of file.

3. R41542 (AS OF ) will select only such records from F4111 which have the
(As of post) IPCD field as ' ' blank.
In case of work orders unless R31802 is run in final mode i.e. status is
brought to 97, the F4111 record of IM & IC will continue having a 'S' flag
for IPCD and hence will not appear in the AS OF FILE.
However, these F4111 records will obviously get considered in F41021 (ITEM
LOCATION) field for Qty on hand.

A: Correct, IPCD='S' records are not included in the As-of. The R41544
which compares the Item Location (F41021) and the Item Ledger tries to
cater for this. It includes F4111 records with a G/L Date = 0 and IPCD <>
'X', therefore your 'S' records.

Regards,

Craig



*********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager ( [email protected])
Important Notice: Berri Limited scans all incoming and outgoing
emails for possible inappropriate content. Procedures to rectify problems with the email system may result in others reviewing
the content of any incoming or outgoing email.
The Berri Limited Email system is for Business use only.
*********************************************************************



Craig Potte
 
Re: 41/IN & integrity reports

Thanks a lot Craig but actually your reply just confirmed my fears that the R41543 is giving maybe misleading results.

However, just one clarification that though we agree that when the R41543 goes in to the DMAAi it only searches for object accounts in tables listed in Rule 3 based on the Doc Co and GL Class combination.

Agreed again that it may get more than one object account for that combination, BUT when it sumarises records found in F4111 and in F0911, it uses a combination of keys which should make only correct comparison possible. These keys are mentioned in the White paper on R41543 as below:
_ _ _ _
' Where Inventory entries are summarized, amounts are added together for all records based on the following keys:

Keys for Item Ledger (F4111)
Document Type (DCT)
Document Number (DOC)
Document Company (KCO)
G/L Date (DGL) based on the processing option value

Keys for AccountLedger (F0911)
Document Type (DCT)
Document Number (DOC)
Document Company (KCO)
G/L Date (DGL) '
_ _ _ _
According to the above, so at a later point it will refer to the document type and hence the irrelevant transactions (which have been selected on account of the serach based on Co & GL class comb.) will get excluded before the final items are printed on the report.

Does my understanding flow in line with the logic of the program ??

Pls send in your views ASAP

Best Regards,

TEJ
 
Re: 41/IN & integrity reports

In reply to... "According to the above, so at a later point it will refer
to the document type and hence the irrelevant transactions (which have been
selected on account of the serach based on Co & GL class comb.) will get
excluded before the final items are printed on the report.

Does my understanding flow in line with the logic of the program ??"

I am not sure that you are understanding this flow correctly...

The integrity report compares the Item Ledger (F4111) values for a Document
with the G/Ledger (F0911) values for the same Document (Document test is
KCO/DOC/DCT/GL Date). The Document Type issue is not with this logic.

It's problem is distinguishing the specific F0911 entries that effect
Inventory Accounts from those that do not effect Inventory Accounts and
that the logic of using the AAI tables irrespective of Document Type can
cause problems if the Non-Inventory Object Account of a document appears
anywhere in one of the selected AAI tables.
*Remember that option 3 includes object accounts from AAI's 4122, 3110,
3910, 4134, 4152, 4162, 4172, 4240, 4241, 4310, 4385, 4330
Hope that this clears this up



*********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager ( [email protected])
Important Notice: Berri Limited scans all incoming and outgoing
emails for possible inappropriate content. Procedures to rectify problems with the email system may result in others reviewing
the content of any incoming or outgoing email.
The Berri Limited Email system is for Business use only.
*********************************************************************



Craig Potte
 
Re: 41/IN & integrity reports

Thanks a lot again Craig for your promt reply.
I understood your views but would better give you an example to make myself clear.
Eg.
F4111
Two records of IM with say GL class = INST
R41543 searches in tables listed under rule 3 for Co and GL class combi. It will look not only in 3110 and 3130 but all others in rule 3.

Lets say it finds some 6 diff object accounts while going thru the tables. Now it will search in F0911 for all occurences of each of those object accounts.
Now when it does this may be it gets several documents in F0911 affecting these accounts. However, it will summarise its find by the above keys of (Doc Type, Co, GL date, Doc No.)
As a result if which lets say in our example it will get three sets of summarized values.

Then logically if will compare these values with like records of F4111. i.e. it will match the summarised values of the two ledgers based on (Doc Type, Co, GL date, Doc No.). As a result of which it will compare only like records, i.e. apples to apples as there would not be more than one occurence in F0911 of the particualr IM docno and type + its Gl date+ IM Company.
In this way the other two sets of summarised values will not be compared at all as they will not match the test of DocNo/ type/Co/Gl date.

I think my understanding is going wrong somewhere as if the above flow is true, than there is very rare chance of R41543 giving misleading results.

Hope the above example is clear to you all.
Your urgent views will be great appreciated.

Many Thanks,

TEJ
 
Re: 41/IN & integrity reports

The logic is a bit different to your post....

It's analysis is done on a document by document basis as follows...

1. The UBE reads F4111 records by Document (KCO/DOC/DCT)
2. On change in Document it calls a BSFN B4100910 (F4111 Check Integrity
with F0911)
3. This BSFN then reads each F4111 record for the document in (1) ONLY, and
accumulates the value (ILPAID)
4. If GL Class of F4111 record not equal to Prev G/L Class
a. Gets the Company (CO) from the Branch/Plant Constants
b. Gets the 41/IN UDC for the Document Type to determine the AAI rule
c. Reads the F4095 AAI Table for each AAI in the rule (eg.
4122,3110,3910,...) using the following tests
i. AAI/CO/GLPT - Company & G/L Class
ii. AAI/CO/'****'
iii. AAI/'00000'/GLPT
iv. AAI/'00000'/'****'
d. For each valid record found it adds the Object on the AAI into an
Array/List (if not already there)
5. When all F4111 records for DOC are read...
6. Reads the F0911 for the the Document in (1) ONLY
7. If the F0911 OBJ is in the Array (4d), accumulates the Amount (GLAA) -
otherwise it ignores
8. When all F0911 records for DOC are read...
9. Compares the value in (3) with the value in (7) and sets an error flag
if different - BSFN Completes
10. UBE prints Error if found

The key problem above is that (4c) does not reference Document Type and
builds a potentially misleading list of valid Objects to be used in (7).



*********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager ( [email protected])
Important Notice: Berri Limited scans all incoming and outgoing
emails for possible inappropriate content. Procedures to rectify problems with the email system may result in others reviewing
the content of any incoming or outgoing email.
The Berri Limited Email system is for Business use only.
*********************************************************************



Craig Potte
 
Re: 41/IN & integrity reports

Hey Craig,
Thats the perfect techno functional explanation which may be i was looking for. Thanks a ton.
But the kind of person i am, i have one more final doubt, which still remains unanswered.:

Your note in step 1
1. The UBE reads F4111 records by Document (KCO/DOC/DCT) -
I hope GL date is also taken into account for creating a set of unique records.

Also, Your note step 6
6. Reads the F0911 for the the Document in (1) ONLY

- Now this means that it will search for a object account (which is in the array) occurence only for the similar combination of F4111 record at 1. i.e. if the step 1 produces a result of Co=00200, Doc No= 123456 and DCT =IM, it will look for records in entire F0911 ''for the same combination'' (of course, in case of IM it will look at F3106 for the GL DOC no.).
If there is any occurence of the 'valid' object accounts in such a combination of F0911 record, it will accumulate the GLAA.

If the above is correct, then i see very little chances of the report giving misleading results. In that i mean to say that the only case of misleading results (apart from the special cases of documents for which you need to set up rule 1 & 2) is where some other AAI is also using the same object account and the IM transaction on hand has recorded a entry using that DMAAI to the same object account as the inventory account. (Eg. In case of OV not being at standard cost, system will record a variance as per 4335 (with same docno, type etc.) , which if you point to the same object account as your 4310 inventory object account, then for GL records it will add up both 4310 & 4335 though it does not check 4335 as per 41/IN)

Hope you agree with my above view, as even if it looks at all DMAAIs there is very rare chance of it finding two diff occurences of DOC No, type, Co in F0911 for the same object account unless as per the example above.

Many thanks for a fast reply,
TEJ
 
Back
Top