Re: RMA History -- BPCS-L

--
[ Picked text/plain from multipart/alternative ]
In a message dated 1/3/2002 2:49:08 AM Central Standard Time,
MacWheel99@aol.com writes:


> Subj:RMA History
> Date:1/3/2002 2:49:08 AM Central Standard Time
> From:<A HREF="mailto:MacWheel99@aol.com";>MacWheel99@aol.com</A>
> Reply-to:<A HREF="mailto:bpcs-l@midrange.com";>bpcs-l@midrange.com</A>
> To:<A HREF="mailto:bpcs-l@midrange.com";>bpcs-l@midrange.com</A>
> Sent from the Internet
>
>
>
> BPCS 405 CD on AS/400 mixed mode
>
> Trying to answer some questions today I discovered that I know entirely too
> little about what is normal for RMA processing.  Looking into some of the
> BPCS files, I find that I am coming away with more confusion than clarity.
>
> Does anyone know off hand if RMAs make it into sales history?
> Are RMAs supposed to get into sales history looking like negative sales?
>
> If they do, is there any easy way to isolate RMA totals so as to eliminate
> them from reports to only show what we sold / shipped, excluding
> involvement
> of customer returns?
>
> If I was looking at this before year end, I could have got it from SSH MTD
> totals, but that door has now been closed on me.  Is there some other door
> that is still open?
>
> We supposedly use one warehouse for customer returns & another for customer
> sales, but looking in the ECL file / RETURN member I can see that the data
> is
> not there consistently according to my understanding of the company rules.
> So I do not know what gets messed up when ECL / RETURN has the wrong
> warehouse.
>
> Evidently ECL file layout does not show a date that the RMA occurred.
> Like ECL *FIRST, it shows when it was supposed to happen, and whether or
> not
> it did happen, but not if it happened this month or whenever.
>
> I can look at invoice line item history to find out when a regular customer
> order shipment occurred, or at the ITH "B" transaction to see price &
> standard cost & actual cost at time of shipment.  I am somewhat at a loss
> where to find equivalent information when a customer return occurred.
>
> I noticed that 100% of our activity in warehouses not used for shipping has
> zero in all YTD fields of SSH.  I had thought that the YTD of SSH was a
> perpetual last 12 months ... or is that zeroed during year end?  I should
> have remembered to check YTD of SSH for shipment warehouses before I left
> the
> office ... I will do that Thursday to see if perhaps some activity never
> populates SSH, other than creating records with zero fields.
>
> Our warehouse # system is 2 digits
> 1st digit is the facility
> 2nd digit is the type of item stored there
> That is the system we now use ... there have been exceptions in the past
>
> Examples using facility 2
> 21 is end items about to be shipped from facility 2
> 22 is manufacturing work in process not finished yet
> 27 is raw materials warehouse ... I am assuming all the SSH stuff that is
> 27
> 47 etc. is related to DRP resupply order fulfillment
> 29 is for QC returns to facility 2 ... I am assuming all the SSH stuff that
> is 29 49 etc. are RMA returns
> However, I found a lot of ECL_RETURN records with warehouse 21 that I
> thought
> should be warehouse 29, but many many more than the discrepancies would
> account for.
>
> I had thought that billing adjustments need line item #s & customer PO#s to
> negate totals on original orders, so that adjustments without item# would
> not
> make it into SSH or SSD.  Meanwhile RMAs appear to be stored in member
> RETURN
> of the various customer order & shipment detail files (EC* & ES*).
>
> Should the grand total of what ends up in SSD on any given item be the same
> as what goes into SSH?
>
> We store List Price for reference in item master & try to catch shipments
> on
> customer orders with missing price or miskeyed price, but sometimes
> something
> slips by us, so to try to catch any mishaps in need of correction, I wrote
> a
> query SSD_OVRIDE to computer pricing average last month SSD.SDSL01 /
> SSD/SDQT01 (excluding SDQT01 EQ 0) & compare result to IIM.ILIST to
> identify
> discrepancies.
> With page break on RCM.CNME customer name, totals only on SSD.SDPROD to
> chart
> one line per item sold that customer: total shipped; average selling price
> in
> the overall month's billing; item list price; difference.
>
> There are some items that look like we shipped some quantity at zero price,
> but I have been told by my co-workers that this did not happen, so that
> raised the question of whether RMAs contaminating my report, or something
> else going wrong.
>
> Analysing history files (ITH SLH etc.) on those items show shipments were
> at
> correct price, but then I had a hard time with how the RMAs came back in
> ...
> is it even possible to link some info in history of customer return
> inventory
> with the customer order (e.g. ECL file RETURN member) which does not seem
> to
> be showing WHEN the transaction occurred.
>
> In one case I was told that we shipped 1000 for the month (and I found in
> the
> history where it was two shipments of 500 each correctly priced), and also
> got a customer return of the 1000 (and I found in the history where the
> 1000
> came in as an inventory adjustment with no $ values associated with it).
> The
> total of the SSD shows we shipped 1000 with no price ... if I am doing this
> right it would stand to reason it would be the other way round ... 0
> shipped
> but price there.
>
> While running queries various different ways against SSH data, I found that
> we had info in the SSH file on warehouses we have not shipped out of in
> over
> a year (such as facility 3 which we closed Dec 1999).
> What controls what customer/item/warehouse goes into SSH?  Some of those
> warehouses took a couple months to get all the stuff cleaned out of BPCS
> after we quit using them for real.
>
> Perhaps my problem is excluding SDQT01 EQ 0 for two reasons ...
> 1. 01 is last month 02 prior month etc & I only wanted to get at last month
> data
> 2. I am not fond of asking computer to divide by zero
>
> On a hunch, I selected how many records have SDQT01 (Quantity for the
> month)
> zero and SDSL01 (Sales dollars for the month) not zero, or the other way
> around SDQT01 not zero and SDSL01 zero ... I found a few of these
> scenarios,
> but they did not explain all the weirdness on my query that my co-workers
> questioning that perhaps RMA ends up in sales history but does not go in
> consistently.
>
> MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
> _______________________________________________
>

Hello,

An RMA is to a credit as a Quote is to an order. Once it has been copied into
an order, it is done. The order carries the  ball from here. As mentioned by
others, this new order carries a reference back to the originating document
such as  RMA or quote or order.
Your choice of order type on the resulting credit will influence which sales
fields will be updated if any. In 405 you are probably limited to warehouse
or even inventory reason code for identifying the categories of credits. If
your are V6 or > you may select from your user defined list of order types
and classes.

"B" transaction? Need some help, but I think this is where the "RM"
transaction comes into play.

Don't think of the RMA only in the literal sense where material is physically
returned. It is sometimes effective as the vehicle for gaining some control
of the whole credit handling process, regardless of the physical disposition
of the product. Sort of a credit request/approval system. Also, an RMA can be
entered from scratch or can be directed to pull the details from the invoice
history. This has the advantage of (A)better accuracy and (B)validation of
the original values. (Hmm, Why are they returning more than we shipped,
interesting.) In any event it will improve the probability that the credit
item/qty/price is the same as the original invoice litem/qty/price. That
should help solve some of the mystery of zero units and non zero sales
dollars in your sales history files.

Regards
Larry