Nick,
Wow. I haven't used FoxPro (great product for small, tight db apps) since ?1993? - but yes: That just might work.
You want to be very careful though with odbc hitting a live db as it can noticeably impact overall performance. Queries must be max optimized and (if you've got the tools) VERY limited criteria (passing very specific parameter variables to use as criteria) to return only exactly what you need.
My observation of the natively supported xml export to (typically Crystal) report generation tools is that it seems to do a decent job of NOT momentarily crippling system performance (as perceived by users) - but the only mechanism to initiate the export (unless using heavily integrated Crystal) is to either manually invoke the export (from BAQ) to xml from within Vantage or tie it to a recurring process set.
Unless you can somehow leverage Service Connect (say from within excel via vbScript calls to the Service connect objects), that doesn't make on-demand reports (other than via heavily integrated Crystal) possible.
Even if you can trace the export process and figure out how to call & initiate it from a vb enabled app (like Excel) - you still have the issue of having the BOs called denying execution from the unlogged in calling app (Excel). (Perhaps Service Connect makes this a non issue though?)
If you are going to seriously consider odbc as a primary way of getting data out of Vantage (since the Progress driver has login rights) - you might want to explore setting up some kind of replication (db) server to keep any odbc load of the primary server that impacts user perceived performance.
Supposedly, there is a product out there to do just that between your Progress db and a 2003 SQL server. Once on SQL server (replicated in real time-enough form) the data could be accessed to your heart's content without fear of slowing (already slow) v8 performance as perceived by users. (Effectiveness & Cost/Benefit you would have to assess and justify).
Progress & FoxPro being far more mature than SQL server, perhaps Progress has something like that for FoxPro (if that is your db of choice).
I've read here on the UG about quite a few people using Access in somewhat this manner.
(Maybe someone out there can provide some more insight?)
Rob
Wow. I haven't used FoxPro (great product for small, tight db apps) since ?1993? - but yes: That just might work.
You want to be very careful though with odbc hitting a live db as it can noticeably impact overall performance. Queries must be max optimized and (if you've got the tools) VERY limited criteria (passing very specific parameter variables to use as criteria) to return only exactly what you need.
My observation of the natively supported xml export to (typically Crystal) report generation tools is that it seems to do a decent job of NOT momentarily crippling system performance (as perceived by users) - but the only mechanism to initiate the export (unless using heavily integrated Crystal) is to either manually invoke the export (from BAQ) to xml from within Vantage or tie it to a recurring process set.
Unless you can somehow leverage Service Connect (say from within excel via vbScript calls to the Service connect objects), that doesn't make on-demand reports (other than via heavily integrated Crystal) possible.
Even if you can trace the export process and figure out how to call & initiate it from a vb enabled app (like Excel) - you still have the issue of having the BOs called denying execution from the unlogged in calling app (Excel). (Perhaps Service Connect makes this a non issue though?)
If you are going to seriously consider odbc as a primary way of getting data out of Vantage (since the Progress driver has login rights) - you might want to explore setting up some kind of replication (db) server to keep any odbc load of the primary server that impacts user perceived performance.
Supposedly, there is a product out there to do just that between your Progress db and a 2003 SQL server. Once on SQL server (replicated in real time-enough form) the data could be accessed to your heart's content without fear of slowing (already slow) v8 performance as perceived by users. (Effectiveness & Cost/Benefit you would have to assess and justify).
Progress & FoxPro being far more mature than SQL server, perhaps Progress has something like that for FoxPro (if that is your db of choice).
I've read here on the UG about quite a few people using Access in somewhat this manner.
(Maybe someone out there can provide some more insight?)
Rob
--- On Mon, 10/13/08, Nick Taylor <n.taylor@...> wrote:
From: Nick Taylor <n.taylor@...>
Subject: RE: [Vantage] Backflushed Parts / Kanbans In 8.03.305K
To: vantage@yahoogroups.com
Date: Monday, October 13, 2008, 3:51 PM
Hmmm, are you suggesting you write something in externally in VB and hit the
Vantage database via ODBC...??
In that case I could use Visual FoxPro ( which I have 20-years + experience
with ) to query the Vantage database, and then construct a temporary table
to do what ever I like... Remember our lot numbers are date/time coded, so
the FIFO is virtually automatic... ;o)
And, I agree, I don't really like Crystal either... :o(
Thanks,
Nick
_____
From: Robert Brown [mailto:robertb_versa@ yahoo.com]
Sent: 13 October :38
To: vantage@yahoogroups .com
Subject: RE: [Vantage] Backflushed Parts / Kanbans In 8.03.305K
Nick,
First off: I DESPISE Crystal (irrationally) - I'm an Excel guy.
That said, I think you can perhaps best do what you want by changing the
standard Crystal pick list.
We don't do lot tracking so I'm not familiar with the tables.
It seems to me though that you should be able to add some subquery logic
that, via some FIFOish logic, only displays the oldest Lot w/ enough O/H to
just cover your requirements being picked.
(I'm assuming you don't want to use multiple lots... If you can, then it
becomes a simple FIFO aging calculation of including each successively newer
and available lot until the total qty is sufficient to just cover your
requirement for each part. Those lots are then the only ones displayed on
the output).
If you are like me and prefer Excel, it would be pretty easy to do the same
w/ vbscripted odbc SQL subqueries where a passed parameter (jobnum) main
query dumps out your requirements and then constructed on the fly (via
vbscript) subqueries do the successive FIFOish processing after being passed
the part & qty req'd target. (That would be done for each requirement. -)
I'd shy away from using excel to push xml back out for Crystal to then use
(if you are even considering it).
Not impossible.
Rob
--- On Mon, 10/13/08, Nick Taylor <n.taylor@kingfield -
<mailto:n.taylor% 40kingfield- electronics. co.uk> -electronics. -co.uk> wrote:
From: Nick Taylor <n.taylor@kingfield -
<mailto:n.taylor% 40kingfield- electronics. co.uk> -electronics. -co.uk>
Subject: RE: [Vantage] Backflushed Parts / Kanbans In 8.03.305K
To: vantage@yahoogroups <mailto:vantage% 40yahoogroups. com> -.com
Date: Monday, October 13, 2008, 1:11 PM
Hmmm... Its a shame they don't get these things right, Vantage would be so
much better if they did... :o(
I'll ask you another question Rob if I may...
If I want to start creating more complex datasets for the purposes of
reporting ( in other words ones that aren't generated by a simple BAQ or SQL
select command ), what are my options ??
If I wanted to run a series of SQL statements and pull together data from a
number of sources and then process it before dumping it out to crystal, how
would I do this ?? Can I do this ??
I'm trying to improve on the picking list report as I really only want to
show a parts lot numbers that should be picked to fulfil the requirement for
a particular job. I don't want to see every lot number currently in
inventory against the part. So if I only want 20pcs, just show me the lots
number necessary to fulfil the requirement, and not everything else...
Ideally getting the data into a dashboard would be great as we can do all
sort of things with it once its there... Yup, you guessed it, Excel to
ServiceConnect. ..!
Any thoughts on how I would do this ??
Its either "really easy", or impossible.. .!
Thanks,
Nick
_____
From: Robert Brown [mailto:robertb_ -versa@ yahoo.com]
Sent: 13 October :30
To: vantage@yahoogroups .com
Subject: RE: [Vantage] Backflushed Parts / Kanbans In 8.03.305K
Thanks Nick.
Actually doesn't sound much worse than VB customization (re lack of
documentation and debugging tools)... I almost always have to resort to
trace logging to get them to behave right.
Thanks again.
Rob
--- On Sun, 10/12/08, Nick Taylor <n.taylor@kingfield -
<mailto:n.taylor% 40kingfield- electronics. co.uk> -electronics. -co.uk>
wrote:
From: Nick Taylor <n.taylor@kingfield -
<mailto:n.taylor% 40kingfield- electronics. co.uk> -electronics. -co.uk>
Subject: RE: [Vantage] Backflushed Parts / Kanbans In 8.03.305K
To: vantage@yahoogroups <mailto:vantage% 40yahoogroups. com> -.com
Date: Sunday, October 12, 2008, 2:51 PM
Hmmm, ServiceConnect Rob, oh here we go again...
First the good bits...
It has the potential to be seriously useful as it exposes just about every
web method for you to play around with. I use it extensively for making mass
changes to existing data ( ok, ok, when we screw it up the first time ), or
for loading new data, and I use it for making block issues from inventory,
or perhaps for moving a load of inventory from one bin location to another.
I have also written routines that load new parts into the MPF from a
spreadsheet but at the same time we load the vendor data and the standard
price. We have had lots of cultural issues where people enter a new part and
then don't bother with the vendor data or other ancillary information. This
is because its multi-department. I now get it all correct in the spreadsheet
first ( typically this is chopped about from customer supplied data usually
in Excel ), and chuck it through s/c and off we go.
Its undoubtedly a very useful tool, and I don't regret buying it.
However....
You just knew there was a catch didn't you...?!
Firstly Epicor do produce a service connect user guide and this does indeed
tell you all the ins and outs of setting it up ( which is easy when you know
how, but a real pig at first ).
But....
THE BOOK DOES NOT TELL YOU HOW THE WEB SERVICES OPERATE OR INDEED WHAT THEY
ACTUALLY DO. Remember also that the web services don't get any nice friendly
wrapper, so if you miss a field ( like RowMod for example ), you are stuffed
and it wont work. Then of course the "error" messages will typically tell
you everything worked ok when clearly it didn't, or it will give you an
error message which is meaningless.
In fact after calling in Epicor to assist me with training ( the guys here
in the UK are very good ), you realise that the only way to write s/c
routines is to start picking apart the tracing logs for any given form so as
to find out what methods each forms calls, and the sequence in which they
are called, and then you can start to understand what fields are required to
get them to work. After you have this you can then start to put together
your s/c routine...
If the documentation was good, s/c would be awesome, but without it, prepare
yourself for some serious frustration. ..!
Thanks,
Nick
_____
From: Robert Brown [mailto:robertb_ -versa@ yahoo.com]
Sent: 11 October :35
To: vantage@yahoogroups .com
Subject: RE: [Vantage] Backflushed Parts / Kanbans In 8.03.305K
Nick,
We don't have Service Connect but the more I hear the more I think it could
help us. If we ever spring for it, I'll be picking your brain for sure.
You're right about KanBan Monitor: A glitzy looking tool that probably
drives some sales during demos to prospective Vantage buyers - but
effectively useless other than for managers or supervisors who want to
occasionally see what is going on.
You can edit right click menus within it so you can launch apps to execute
what it suggests - but that doesn't work well on a shop floor. The execution
actions should be internal to the app. It probably wouldn't be hard to
customize to give it some easy access execution capability.
Frankly, I never thought about it until now... Thanks for waking up my brain
(as maybe I'll give it a go).
Rob
--- On Sat, 10/11/08, Nick Taylor <n.taylor@kingfield -
<mailto:n.taylor% 40kingfield- electronics. co.uk> -electronics. -co.uk>
wrote:
From: Nick Taylor <n.taylor@kingfield -
<mailto:n.taylor% 40kingfield- electronics. co.uk> -electronics. -co.uk>
Subject: RE: [Vantage] Backflushed Parts / Kanbans In 8.03.305K
To: vantage@yahoogroups <mailto:vantage% 40yahoogroups. com> -.com
Date: Saturday, October 11, 2008, 2:50 AM
We could talk about this all day Rob...!
Its almost easier just to mass-issue all the "C" class stuff as the job gets
released and do it that way - this is what we are doing now. At least then
all the fasteners get expensed to the jobs properly,and the job tracker
shows the true state.
I have written a number of ServiceConnect routines that I use for
mass-transactions on the system. Generally these work well, however I
usually have to write a BAQ to go along with it so that I can get the data I
want initially. I then drop this into the appropriate Excel template, push
it through ServiceConnect, and bingo, we can issue lots of things all in one
go. This is the way we are issuing lot traced parts from inventory during
the job picking process. In the future we are going to use more buy-direct
parts. This also has the benefit of stopping MRP being, well, MRP as this is
not right for our business. In fact, we spend most of our time trying to
stop MRP being MRP...!
The KanBan monitor strikes me as something that looks good but doesn't
really bring anything tangible to the party. If all it is going to do is
generate the need for yet more inventory transactions, then we will stop
using it. We are in danger of spending more time doing the paperwork that
the job takes to build!!
Lets not go there about excessive inventory and MRP Rob... :o(
I will give the matter some more thought I think...
Thanks,
Nick
_____
From: Robert Brown [mailto:robertb_ -versa@ yahoo.com]
Sent: 11 October :36
To: vantage@yahoogroups .com
Subject: Re: [Vantage] Backflushed Parts / Kanbans In 8.03.305K
You did your homework Nick.
No elegant native way to do mass whse/bin to wshe/bin kanban transfers.
(Yes: A disappointment. -)
Yes: Backflushing only occurs after labor qty complete for the associated
Job Op is entered.
If these are gold plated parts, you should probably be issuing them to WIP
anyway.
If they are common parts, from a planning perspective it doesn't really
matter much if they are consumed in WIP or just still soft allocated to the
Job Op.
If an Op may linger open for months though - you might want to associate
them with the prior Op so they are consumed into WIP when the prior OP
completes. That prior Op could be a zero time/cost dummy Op that is a labor
entry point to simply tell the job to go backflush all your parts as the
real Op is about to start.
It all depends upon your process needs. Issue to early and the 'black hole'
of WIP hides material that could otherwise be used on another job (and still
replaced in time for the originally intended job). Issue to late and other
jobs can slip in ahead of the originally intended job and it you can find
yourself in a spot where it can't be replaced promptly enough.
Job tracker does have the data view available to display if a material is
backflush or Issue-only. I don't recall if the base app displayed it on your
version but you can customize to do so in both the material detail and list
view tabs. No such capability for the tree view though.
MRP and KanBan: They are absolutely not systemically mutually exclusive -
but it can be very confusing to buyers/planners to use them both on a part
as they are polar opposite paradigms. (MRP is a 'push' replen paradigm to
meet actual or expected demand and KanBan is 'pull' replen upon
consumption. -)
If your people are comfortable with MRP, keep it on for 'a while' for your
KanBan items as a safety net until your people gain (some) comfort in KanBan
- but then turn of MRP for KanBan parts. You'll probably have to force the
issue as people like what they are used to.
If your people aren't MRP biased - good for them as it is an over applied
paradigm that just isn't that good in the real world... It is a crutch that
more often does more harm than good and has created trillions of dollars of
dead inventory since it saw widespread attempted use - Just use KanBan and
turn off MRP on those items.
We haven't decided yet whether to use purchased type kanbans or just use
contract POs. Unfortunately, they are mutually exclusive (systemically) and
they shouldn't be. Purchased type Kanbans require a preagreement with the
supplier for rapid replen or the kanban will fail. What better way than
(systemically) to have a contract PO to draw from?
Ah well... Maybe v9.
Hope that makes sense.
Rob
--- On Fri, 10/10/08, nmtaylor1969 <n.taylor@kingfield -
<mailto:n.taylor% 40kingfield- electronics. co.uk> -electronics. -co.uk>
wrote:
From: nmtaylor1969 <n.taylor@kingfield -
<mailto:n.taylor% 40kingfield- electronics. co.uk> -electronics. -co.uk>
Subject: [Vantage] Backflushed Parts / Kanbans In 8.03.305K
To: vantage@yahoogroups <mailto:vantage% 40yahoogroups. com> -.com
Date: Friday, October 10, 2008, 8:58 AM
Can anyone ( Rob!? ) offer any best practice advice on the use of back-
flushed parts and kanbans in Vantage...
We have a particular build cell ( defined as a specific resource within
a resource group ) in which we build a specific range of products. All
the fasteners used in this area have been defined as back-flushed
within the MPF, and have been associated with the appropriate labour
operation on the MOM. They have also been allocated a warehouse bin
which is the nominated back-flush bin within the resource itself. We
have set a min/max level on this bin and a KanBan replenishment so as
to pull stock from the bulk storage location in our main stores area.
This bin also has a min/max on it which is the trigger to call in
additional inventory from the outside world.
Using the KanBan bin monitor we can now see requests to pull materials
from the bulk store to fufil the warehouse bin min/max demand. This all
seems logical.
I am expecting to see a quick and easy way to make the inventory
movement so as to fulfil the warehouse bin demand and satisfy the
KanBan request. But it seems the only way to do it is to move the
inventory on Vantage from the bulk store bin to the warehouse bin one
line at a time. This all seems rather tedious...! Am I missing
something somewhere... ?
Also, am I correct in thinking that the back-flush process only takes
place when the job operation ( which the parts are tied to within the
MOM ) is fully completed. Therefore if I have a job open for a couple
of months, we are only going to consume the parts at the very end... I
am worried that this might be too late in the game... Am I missing the
point here...?
Why doesn't the job tracker indicate that the parts are back-flushed
and therefore dont need kitting. Shouldn't there be a different
coloured tick or something... ? ( Not that these work properly anyway! )
Any help on managing "C" class parts would be most helpful, as the
above still seems far too complicated. Should I just turn MRP off and
run them via manual KanBans...!?
Many thanks,
Nick
This email and its attachments may be confidential and are intended solely
for the use of the individual to whom it is addressed. Any views or
opinions expressed are solely those of the author and do not necessarily
represent those of Kingfield Electronics Ltd. If you are not the intended
recipient of this email and its attachments, you must take no action based
upon them, nor must you copy or show them to anyone. Please contact the
sender if you believe you have received this email in error.
Kingfield Electronics Ltd., Carrwood House, Carrwood Road, Chesterfield
Trading Estate, Chesterfield S41 9QB, United Kingdom. Place of
registration: England. Company registered number: . Telephone:
+- .
[Non-text portions of this message have been removed]
This email and its attachments may be confidential and are intended solely
for the use of the individual to whom it is addressed. Any views or
opinions expressed are solely those of the author and do not necessarily
represent those of Kingfield Electronics Ltd. If you are not the intended
recipient of this email and its attachments, you must take no action based
upon them, nor must you copy or show them to anyone. Please contact the
sender if you believe you have received this email in error.
Kingfield Electronics Ltd., Carrwood House, Carrwood Road, Chesterfield
Trading Estate, Chesterfield S41 9QB, United Kingdom. Place of
registration: England. Company registered number: . Telephone:
+- .
[Non-text portions of this message have been removed]
This email and its attachments may be confidential and are intended solely
for the use of the individual to whom it is addressed. Any views or
opinions expressed are solely those of the author and do not necessarily
represent those of Kingfield Electronics Ltd. If you are not the intended
recipient of this email and its attachments, you must take no action based
upon them, nor must you copy or show them to anyone. Please contact the
sender if you believe you have received this email in error.
Kingfield Electronics Ltd., Carrwood House, Carrwood Road, Chesterfield
Trading Estate, Chesterfield S41 9QB, United Kingdom. Place of
registration: England. Company registered number: . Telephone:
+- .
[Non-text portions of this message have been removed]
This email and its attachments may be confidential and are intended solely
for the use of the individual to whom it is addressed. Any views or
opinions expressed are solely those of the author and do not necessarily
represent those of Kingfield Electronics Ltd. If you are not the intended
recipient of this email and its attachments, you must take no action based
upon them, nor must you copy or show them to anyone. Please contact the
sender if you believe you have received this email in error.
Kingfield Electronics Ltd., Carrwood House, Carrwood Road, Chesterfield
Trading Estate, Chesterfield S41 9QB, United Kingdom. Place of
registration: England. Company registered number: . Telephone:
+- .
[Non-text portions of this message have been removed]