Received: from localhost (unknown [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id BC7E09FB26A for ; Tue, 16 Oct 2007 05:27:28 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 76369-04 for ; Tue, 16 Oct 2007 05:27:14 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from pih-relay06.plus.net (pih-relay06.plus.net [212.159.14.133]) by postgresql.org (Postfix) with ESMTP id 029A49FA558 for ; Tue, 16 Oct 2007 05:27:22 -0300 (ADT) Received: from [84.51.143.99] (helo=server3.office.archonet.com) by pih-relay06.plus.net with esmtp (Exim) id 1Ihhlp-0003Ax-EJ; Tue, 16 Oct 2007 09:27:21 +0100 Received: from [192.168.1.36] (dell36.office.archonet.com [192.168.1.36]) by server3.office.archonet.com (Postfix) with ESMTP id 844DF274057; Tue, 16 Oct 2007 09:27:20 +0100 (BST) Message-ID: <471475E8.4030505@archonet.com> Date: Tue, 16 Oct 2007 09:27:20 +0100 From: Richard Huxton User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Mike Adams CC: pgsql-sql Subject: Re: Refactored queries needing validation of syntactic equivalence References: <470D5F81.5090403@comcast.net> <470DCFC7.3090901@archonet.com> <47110414.6060907@comcast.net> In-Reply-To: <47110414.6060907@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200710/67 X-Sequence-Number: 29439 Mike Adams wrote: > So..... > The first query should pull all 'MOM' records that have one or more > corresponding, and possibly orphaned, unassigned receiving records > belonging to the same po_cd and item_cd. > > The second query should pull all unassigned, and possibly orphaned > receiving records that have one or more corresponding 'MOM' records once > again matching on po_cd and item_cd. > > Using the results of both queries to double check each other, I can > figure out which (if any) open records are, in fact, orphans and do an > "after the fact" assignment to the "SPLIT IN MOM" invoice to reduce our > accrual. > > Of course, our ERMS should take care of this automagically; but, > tragically, it seems "real" inventory cost flow was attached to the > system using duct tape, hot glue, and a couple of thumb tacks. > > So, given all the administriva above, have I actually refactored them > correctly? Well, clearly you could have multiple possible matches, because apart from anything else you could in theory have multiple entries with the same item-code on the same purchase-order-code. In practice it will be rare, but it could happen. However, since the purpose is to provide you with a list so you can make manual changes there's no problem with that. What I might be tempted to do is restrict the dates more - you had <= '31 Oct 2007' I'd also apply >= '1 Aug 2007' (or whatever period is reasonable). You can always run an unconstrained match once a month to catch any that slip through the net, but presumably most will fall within a 90-day period. HTH -- Richard Huxton Archonet Ltd