× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



we are on version 6.04; mixed mode.

RMA's are open receipts; turned into credits when the inventory is received 
from the customer. So, RMA's do indeed go to sales history where, typically, 
they would be considered a return from the customer and, hence, a credit. Sales 
history has other credits (for our business), so it is probably not a good 
place to look for shipments.

Never trusted SSH, SSD, RCM buckets etc not only because of possible coding 
errors, but because of some of the things our business puts through as credits. 
The totals would never be right.

In 6.04, RMA's are put to a different file; so, if I wanted to get to our 
shipments I would just look at ech/ecl and select the order types I am 
interested in. If you go to ITH, you will have to marry it back up to ECH .... 
unmatched records would be RMA's; there are other possible records you may want 
to reject based upon customer, order type, etc.
> ----------
> From:         MacWheel99@aol.com[SMTP:MacWheel99@aol.com]
> Reply To:     bpcs-l@midrange.com
> Sent:         Thursday, January 03, 2002 2:47 AM
> To:   bpcs-l@midrange.com
> Subject:      RMA History
>
> 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)
> _______________________________________________
> This is the SSA's BPCS ERP System (BPCS-L) mailing list
> To post a message email: BPCS-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/bpcs-l
> or email: BPCS-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/bpcs-l.
>
>


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.