TraceTrack

Trace/Track Lot

Minor Business Rule

Object Name: B3003610

Parent DLL: CMFGBASE

Location: Client/Server

Language: C

Functional Description

This business funtion is passed in lot information to trace, and "returns" a cache loaded with the results.  The user then call the cache handler to 
output the results.

Approach 

The business function has 2 main functions.  The first is to load the cache with Cardex information of transactions that put into inventory for tracing, 
and pull from inventory for tracking.  The second is to trace or track information on processes where a change in lot information may occur, such as work 
orders, transfers, and reclassifications.  The definition here of a change in lot information is that a different Lot Master (F4108) record describes the 
"FROM" record and the "TO" record.  Each of these process types uses a different method of determining where the lot came from or went to, so each type is 
handled differently.  If another process is created that can change lot information, a new section needs to be created (probably using an existing type as a 
template), and the "trigger value" entered in UDC ??/DC (default = 40/DC), and the new process should work.  

Assumptions

The following is a description of what information is needed for each process type where lot changes may occur:

Work Order Completions  tracing:

For a work order completion to be traced, there must be work order issues where the Cardex document number ILDOC is the same for both 
issues and completions.  The program finds Cardex records with the document number equal to the completion document number AND the document type 
NOT equal to the completion document type (no need to process completions again.)  For each record processed in the result set, it is verified the record 
type is a work order issue type.

Work Order Issues  tracking:

For a work order issue to be tracked, there must be work order completions where the Cardex document number ILDOC is the same for both 
issues and completions.  The program finds Cardex records with the document number equal to the issue document number AND the document type NOT 
equal to the issue document type (no need to process issues again.)  For each record processed in the result set, it is verified the record type is a work 
order completion type.

Reclassifications  tracing:

The reclassification program writes a transaction's "FROM" records to the Cardex before writing the "TO" records for that transaction.  If 
there are multiple reclassifications on a document, the "FROM" records of the first transaction are followed by the "TO" records of the first transaction, 
followed by the "FROM" records of the second transaction, followed by the "TO" records of the second transaction, and so forth.  At the time of coding this, 
there was a discrepancy in the number of "FROM" records written to the Cardex.  For the purposes of this exercise, all that needs to be done is to sum the 
quantities for each "set" of "FROM" records, write the summation record to the cache, then trace the information on the summation record.   

Reclassifications  tracking:

Tracking reclassifications consists of consolidating "FROM" records (see Reclassifications  tracing), then storing and tracking the "TO" 
record(s). 

Transfers  tracing:

To determine the Cardex record to get for a transfer, look for the same document number and document type, and the line ID equal to the 
whole number portion of the "TO" record's line ID.  In a transfer, the "FROM" record has a whole number line ID, and the "TO" record has the whole number 
plus a fraction amount.

Transfers  tracking:

To determine the Cardex record to get for a transfer, look for the same document number and document type, and the line ID greater than 
current line ID, but less than the current line ID + 1.

Assumptions (cont'd)

Consolidations 

Consolidations in its simple form is the combination of records sharing the same characteristics.  For example, if there is a receipt with duplicate 
lines, adding the quantities into one record and displaying it might be desirable.  The difficulty comes in consolidating types where a lot change may occur.  
For instance, if work orders (tracing) were to be consolidated, the duplicate completions would be summed correctly.  However, each completion would 
trace the same group of issues, thereby causing the consolidated issue totals to be a multiple of what they really should be.  
The solution is to not trace or track (in a lot change situation) if the original record has been consolidated.  Also, the consolidations must be 
performed in the right grouping of records.  In other words, a unique F4111 record must never be consolidated with itself.  This is accomplished by only 
allowing a consolidation to occur within a specific trigger.  For instance, say there are 2 identical completions to be traced, and the completions are not to be 
consolidated, but the issues are.  The consolidations for the issues of the second completion record must not be mixed with the consolidations for the issues 
of the first completion.  The unique key ID of the F4111 record is used as part of the consolidation criteria to ensure consolidations only occur within that 
record.  
Currently, work orders and reclassifications are covered by this scenario.  Transfers are not allowed to be consolidated.  A successful transfer 
consolidation would have to make sure BOTH the "TO" AND "FROM" records were consolidated correctly.  This is not currently programmed.

Intermediate Levels
A particular node being traced/tracked is defined as an intermediate level if that node can be traced/tracked and that action causes additional 
records to be written to the cache.  If a node cannot be traced/tracked further, it is not an intermediate level.  If a node can be traced further, but no more 
records are written to the cache, that node is not an intermediate level.
The algorithm is then to write a cache record for work order completions in tracing or work order issues in tracking.  If while tracing/tracking the 
work order, if records were added to the cache, the initial cache record is removed.  The same method is applied inside the tracecompletions / trackissues 
functions, as well as in the reclassifications functions and transfer functions.  Cache is not updated in trace/trackmain for reclassifications or transfers 
because there must be "FROM" record(s) for each "TO" record(s).  We know there will always be a cache record added, so there's no point in adding it just to 
delete it.

Document Type Processing

Currently, UDC table 40/DC is used to determine what type of processing is to be done with a specific document type.  This program attempts to 
allow for future flexibility by assigning multiple flags to a document type within function GetUDC40/DCInfo.  Processing flag values specific to a 
document type should be retrieved or hard coded here.  At this time, many of these values are hard coded, but when a method of allowing users to decide the 
processing is implemented, GetUDC40/DCInfo is the only place that will need to be modified.

Setup Notes and Prerequisites

UDC table ??/DC (default = 40/DC) must have its second description field filled in as follows for each document type function:
Work order completion: M - Completion
Work order issue:I - Issue
Reclassification:R - Reclassification
Transfer:T - Transfer
Bottom level (sales orders)B - Bottom Level 
Top level (purchase orders)C - Top Level

Technical Specification

Usage:

1.B3003610 Trace/Track is called.  This loads the cache. 
2.B3003600 Cache is called to read the first record.
3.While there are cache records:
3a.Read data from the cache structure.
3b.Read the next cache record using B3003600.
4.Destroy the cache (B3003600)

Parameters (B3003610 Trace/Track)

INPUT
szLotLot Number to be Traced/Tracked
szBranchBranch Number to be Traced/Tracked
mnItemNumItem Number to be Traced/Tracked
cUniqueLotsFlag1 = Lot#, 2 = Lot#, Branch, and Item, 3 = Lot# and Branch
cTraceTrack'1' for Track, anything else for Trace
mnCurrentLevelThe starting level assigned to the input data to be traced/tracked.
mnStoppingLevelIf greater than zero, the highest level to be traced/tracked through
cShowBottomTopLevelIf 1, show bottom/top level transactions, else do not show 
cShowIntermediateLevelsIf 1, show intermediate levels, else do not show
mnJobnumberJob Number for cache
szComputerIDComputer ID for cache
szUDCSystemCodeOverrides UDC table 40/DC. I.e. entering 37 will use UDC 37/DC.

OUTPUT
mnRecordCounttotal # of records added by this iteration and subsequent calls


^

Data Structure

D3003610A - Trace/Track

Related Functions

Related Tables