ISTech Support Forum
http://www.istechforum.com/YaBB.pl Evo-ERP and DBA Classic >> Sales >> Sales Analysis http://www.istechforum.com/YaBB.pl?num=1088460263 Message started by jamfg on 06/28/04 at 14:04:23 |
Title: Sales Analysis Post by jamfg on 06/28/04 at 14:04:23 Sales Analysis, Daily Booking Report gives options for sales or bookings. HOWEVER, there doesnt seems to be a difference between the two. I'm looking for a report that will show $ sales "booked" for a time range, regardless of what has shipped. Is there such a creature in DBA? :-X |
Title: Re: Sales Analysis Post by Lynn Pantic on 06/28/04 at 14:50:32 SA-A Bookings lists both Open and Closed Bookings. Open Bookings have not yet shipped; closed bookings are shipped. |
Title: Re: Sales Analysis Post by jamfg on 06/29/04 at 07:29:40 No matter which way I run this report, all I get are INVOICED totals. What I'm looking for is a listing of "orders taken" for a specific time frame. I would think that would be considered bookings, but if I run the list by bookings, all I get are shipped orders. If I run the list by sales, all I get are shipped orders. :'( |
Title: Re: Sales Analysis Post by Lynn Pantic on 06/29/04 at 07:57:03 If you run for Bookings, you should get open orders. Make sure you don't enter anything in the From/Thru Invoice date - open orders have no invoice yet so if you enter a date range you are excluuding them. Enter a range of order date, not invoice date. |
Title: Re: Sales Analysis Post by jamfg on 06/29/04 at 10:48:18 Once again, you've saved the day! Thanks ;D |
Title: Re: Sales Analysis Post by jamfg on 06/29/04 at 14:18:12 One small detail and I promise to file this one away. This report splits totals by closed first and then open. Not a problem. However, the totals showing as closed are the same figures in both "Closed Booking Total" and "June MTD Total". HOWEVER, that is NOT correct. I ran this report for dates 6/14-6/20. The total is right for that time frame, but not for MTD. In the Open report, those numbers are different! The "open booking total" is correct, but the "June MTD total" is a totally different number and it is very very much lower than the open total. WHY? |
Title: Re: Sales Analysis Post by jamfg on 07/06/04 at 14:40:53 I never got a response, anyone have any ideas where I went wrong? Skye |
Title: Re: Sales Analysis Post by gtladmin on 07/14/04 at 07:54:39 Hi, We are having some sort of the same issue with our Bookings reports. It seems that since July 6th or 7th, our numbers for bookings are off by a substantial amount. We balanced to our financials report for month ending June, which is after we updated to 2002.4 with the service pack. Our accounting folks think it may be something in the latest update applied. * I am not yet convinced of this. * I wanted to get ideas from people as to things to check. Acftng is comparing bookings reports just run covering January through July, to reports previously run before we updated DBA to 2002.4, and there are sales orders missing from the latest run report that were showing in previous months as far back as January. Could it be something in the way the reports are being run? Could it be something changed during the regular month end routine? They wanted to know if bookings are handled differently in the latest DBA version and/or updates. I said I didnt' think so, there's nothing in any of the what's new info to suggest this. Also, can someone explain the change info at the end of the bookings report? This was not there before? I know this may seem a bit of a vague posting, but I am just wondering if anyone else has seen discrepancies of the same sort, and if they've pinpointed it to a user issue or a likely problem with the latest update. As our number is substantial, I have to get to the bottom of this issue soon. TIA for whatever help or tips can be provided! |
Title: UPDATE: Re: Sales Analysis Post by gtladmin on 07/14/04 at 09:51:26 After some drilling into this a little more, it may be a problem with the update...? As I stated, our accounting folks have noticed that if they run the SA-A bookings, the total is substantially off from what it should be (is less than). They've noticed that the totals they are getting are missing line items from blanket sales orders. It appears the bookings only include the first unshipped line item in the order; no other line items are included even if they are unshipped. This is what appears to be making the numbers not show correctly. If they do SA-A for open orders, the totals are indeed correct and all line items are being included. Can someone please check further on this? Thanks, Val |
Title: Re: Sales Analysis Post by Lynn Pantic on 07/14/04 at 11:19:57 The Change section at the end of SA-A is new, and it includes changes (assuming you have turned Sales Order Change tracking on in SD-Q) to Sales Orders that were entered during the date range specofoed to orders that were created prior to the date range. As for your most recent post, Val, I don't understand what you mean by comparing SA-A Bookings to SA-A open orders. A booking IS an open order ??? |
Title: Re: Sales Analysis Post by gtladmin on 07/14/04 at 14:14:49 Hi Lynn, Hopefully I can clarify this a little more.... We run the SA-A report with dates 1/1/04-7/14/04 and type "B" to tie to our YTD Bookings. We have found that this figure is now substantially lower than our spreadsheet where we track the same information from DBA. After some investigation we think that this SA-A report is only picking up the first line item on open orders and not any future line item orders, resulting in a substantially less figure. The reason I beleive this is true is that we looked at one sales order on both reports and the total open amount was different. It was the full order amount on SO-O-A and only the first line item total on the SA-A report. I hope this helps clarify the problem we are having. Thanks. |
Title: Re: Sales Analysis Post by Laura on 07/14/04 at 14:32:38 Could Val's reasoning be the explantion for the problem I mentioned in my last problem ? My Gl-D says . but . my SA-M says 50000-200 $1500.00 50000-200 $1450.00 50000-300 $ 150.00 50000-300 $135.00 50000-400 $ 800.00 50000-400 $865.00 ________________________________________ . . . $2450.00 . . . . $2450.00 The bottom lines match but the depts are out of whack. It was stated in an earlier post that SA-M is correct. But SA-M does N O T match what GL-O sent to the financial statements. I can't find the problem. The real $$ figures aren't this simple I never had this problem before either. Thanks Laura |
Title: Re: Sales Analysis Post by Lynn Pantic on 07/14/04 at 17:00:09 Laura - I think your problem is because you entered GL Accounts in the AR-A screen for customers. See my response to your other post. |
Title: Re: Sales Analysis Post by Laura on 07/14/04 at 18:38:20 No!!! I had only 2 or 3 customers that had the GL class on AR-A. Yes...it caused a little problem. BUT: ... I figured (2) things out: (A) We have 5 departments that do JOURNAL REPAIR. Most of the time it is done by dept 400, but occasionaly another dept does it) So if dept 200 does it on June 1 we go into IN-b and change the product class to 200. Then if dept 400 does one on June 15th we go back into IN-B and change the class to 400. This works great on the GL side...The sale gets posted to the correct GL account. But the SA-M always gives the sale to the last class on the part#. (even if you change it months later) I experimented and found that I could change the class on a part# that we shipped months ago. It immediantly changes the SA-m report. Of course changing the class n IN-B after the fact doesn;t effect a posted sale.....but it does effect SA-m. DAMAGE: no GL damage, credit for the sale was posted correctly to the GL. GL is correct/SA-m is wrong. (B) SA-M always uses product class from IN-B regardless what AR-A has. So when we sold item#1000abc that had the correct class of 300 to customer ACME that had the wrong class of 400 there was confusion. Credit for the sale went in two different directions: . IN-b gave SA-m the class & . AR-A gave the GL the class DAMAGE: As a result dept 300 got jipped of the sale in the GL. & dept 400 got undeserved sales. THE GL is wrong. but SA-m is correct. MY QUESTION: Shouldn't SA-M reflect the class of the item at the time it was posted? |
Title: Re: Sales Analysis Post by gtladmin on 07/15/04 at 09:02:04 Anything more on this? Has anyone else seen this problem?? We are at at loss here and need some help. We rely heavily on the SA-A bookings report. TIA, |
Title: Re: Sales Analysis Post by gtladmin on 07/19/04 at 08:34:56 Following up again--Lynn, any ideas here? Can I perhaps send you a few PDFs of what we are seeing so you can take a closer look? This is really a problem for us. TIA |
Title: Re: Sales Analysis Post by iliadmin on 07/20/04 at 12:12:31 Here I go again, posting to myself... It's like a web blog! ;) Since I don't hear anyone else having these same issues with SA-A, perhaps we have some weird data corruption. Would reindexing files maybe help? What files would I try to reindex to see if it clears up the problem? Would the issue of SO-H being incorrect in places also point to some data file amiss? I have delved into this SA-A problem even more, and see that it's not on all blanket orders we have this problem. I found some blanket orders that are fine. I did notice that the cost on all of these is negative in the SA-A Bookings report. I have not found any other commonality between which sales orders show up incorrectly versus ones that appear correct. Uh, any ides/suggestions? ??? TIA |
Title: Re: Sales Analysis Post by Karen Mason on 07/20/04 at 13:45:25 We have found that the BOOKINGS are off when we are combining items setup as individual releases. We increase a release as we are releasing it for invoicing. Then we decrease the next release to compensate. Only the DECREASE is showing up in bookings as a change to bookings, causing the booking report to be under-reported. Both items would need reported to make it accurate. Obviously many of us are relying on the bookings report and we need to resolve where all the discrepancies are coming from. |
Title: Re: Sales Analysis Post by Lynn Pantic on 07/20/04 at 16:04:09 If you are seeing the decrease as a change in bookings, you should also be seeing the increase. if you change the quantity of a SO line, for the Sales Order Change program to record the change, you need to respond Y to the question about changing the Original Order Quantity - that is what the Change Tracking program is picking up on. Also, if a line is eliminated, you need to keep the line in the order and change the quantity to 0, not delete the line or the change tracking won't pick up the change. I did just send Val an updated SA-A, preview of the next post to see if it helps the problems she described. It looks OK in my testing but it is tough to test all the possibilities. I had new orders posted within the date range, they correstly posted as closed bookings; new orders within the date range correctly listed as open bookings and 2 changes to prior orders, one posted and one ont posted, both were listed as changed nbookings only for the amount of the change which is correct because the orders were originally entered prior ro the date range. |
Title: Re: Sales Analysis Post by Karen Mason on 07/21/04 at 06:42:06 We are changing the quantity when we are in SO-E, release sales order. In SA-A, these quantity changes are not being picked up by the change order tracking for the period they are happening in. However, it does come up in closed bookings if the range includes the original sales order date. It also appears that the second line item is not showing up in changes to bookings. They show up in open orders for incorrect amounts. We'll detail all of our transactions in an e-mail to you, Lynn. |
Title: Re: Sales Analysis Post by Lynn Pantic on 07/21/04 at 08:15:48 The current program will only pick up changes if they are made in SO-A, not SO-E. I did get feedback from Val that the version I sent her yesterday resolved her issues, I am uploading the new post now so you will soon get email with the password. |
Title: Re: Sales Analysis Post by gtladmin on 07/21/04 at 10:03:02 ;D Yep, it worked like a charm! Thanks again, Lynn! You're great! Val |
ISTech Support Forum » Powered by YaBB 2.1! YaBB © 2000-2005. All Rights Reserved. |