Customer Order Export

I whipped up a new menu item and the sales people love it and it stops them
asking me for order history reports all the time.

I copied one of my other udXXXX.w modules as udCustomerHistory.w, it prompts
for customer name and runs ...

~~~~~ snip ~~~~~
OUTPUT TO "H:\VntgWork\CustHist.csv".

PUT '"Customer","Date","Order","Line","Part","Price","Qty"~n'.

for each Customer Where Customer.Company = 'ContConv'
and Customer.Name BEGINS cCustomer:SCREEN-VALUE no-lock,
each OrderHed Where OrderHed.Company = Customer.Company
and OrderHed.CustNum = Customer.CustNum no-lock,
each OrderDtl Where OrderDtl.Company = OrderHed.Company
and OrderDtl.OrderNum = OrderHed.OrderNum no-lock,
each Part Where Part.Company = OrderDtl.Company
and Part.PartNum = OrderDtl.PartNum no-lock
BY OrderHed.OrderDate:

EXPORT DELIMITER ","
Customer.Name
OrderHed.OrderDate
OrderHed.OrderNum
OrderDtl.OrderLine
OrderDtl.PartNum
OrderDtl.UnitPrice
OrderDtl.OrderQty.
END.

OUTPUT CLOSE.

run opendoc("t:\vantage\ud\CustomerHistory.xls.").
~~~~~ snip ~~~~~

Then the Auto_Open macro in CustomerHistory.xls opens
\VntgWork\CustHist.csv, changes column widths, adds a 'value' column, adds
some borders, saves the CSV as XLS and closes itself leaving a formatted
CustHist.XLS open. People can then easily remove, sort, pivot, etc to get
the data they are after. Because the SQL statement uses BEGINS you don't
have to type the whole name. It works REALLY quickly too (I like to cheat
and get my SQL from the Export utility).

If anyone wants the .w or .xls drop me a line or if the interest is more
than a couple I will post to the 4GL section.

Regards
Michael
I just wanted to post this so that someone who does the stupid thing we did
later can think back and say "I remember someone posted something about this
once" and find the solution.
Someone here got a little excited after we upgraded to 5.0 and installed
MRP. They wanted to see what it does. They ran MRP only to find that we
have a bunch of work to do on our data before we were ready for that. It
created some 790 some odd unfirm jobs for us. Just think of all the time it
saved from manually entering them. Unfortunately, we did not really want
any of them on the system yet. After a call or two to support and a talk
with a couple Epicor reps at a User Group Meeting I found the real solution
to get rid of all those jobs. The initial thought was to firm, engineer and
release every job and then delete it. After about 400 the simple answer
came..."Just remove the requirement that is creating the job and rerun MRP".
Once the requirements have been removed, the unfirm jobs will be deleted and
not recreated. Great, now all I had to do is go through every part in the
part master and remove the check from "include in MRP". With another call
to support, Craig saw to it that I got this great utility that will allow
you to check and or uncheck every part for either include in MRP or Include
in Suggestions. Now there is a great utility for someone starting out with
MRP.
Anyway, I wanted to get the word out so that it would be back in the memory
banks if anyone ever ran into a similar situation.
Good luck and as always, I hope this helps.

Aaron Hoyt
Information Systems Manager
Design Standards Corp.
PO Box 1620
Charlestown, NH 03603
Tel 603-826-7744
<mailto:aaron.hoyt@...>
Has anyone else running version 5.0 or 5.1 noticed in the Job Tracker the
Last Opr and Wrk Cnt fields now reflect the "Highest" Job Operation Number
and Workcenter that have labor collected against them, as opposed to the
"Last Operation". This presents our users which a huge problem tracking
jobs. If someone mistakenly clocks in on operation 100 when they should be
on operation 10, the Job Tracker will show the Job at operation 100 no
matter where it is in the production process until it passes operation 100.
I contacted Epicor and was told this is the way the system had performed in
version 4 as well. So, I reloaded my version 4 database only to find the
Job Tracker reflects the Last Operation labor was collected on, as opposed
to the Highest Numbered Operation. The 20 or so calls a day from my users
was another indication it had also changed. I was also told their QA
Department checked and there was no change to the program logic. So
thinking it could be just my system (not likely) I contacted 2 members of
this list offline that were still on version 4 and asked them to perform a
test, and they both responded the Job Tracker reflects the Last Operation,
not Highest Operation number labor has been collected against. Can anyone
else verify this for me, or is there a setting that I do not know about. We
are currently on version 5.00.337 and testing version 5.10.113.

Thanks,

Michael Benedict
IS Manager
Cretview Aerospace
Michael,

On our 5.10.113 the tracker is correctly reflecting the last
operation and workcenter that labor was collected on. We are
using Data Collection on the shop floor.

have fun,
john



> -----Original Message-----
> From: Michael Benedict [mailto:mbenedict@...]
> Sent: Monday, January 21, 2002 6:57 AM
> To: vantage@yahoogroups.com
> Subject: [Vantage] Version 5.0 and 5.1 Job Tracker