Karl,
Wow. That's a pretty neat idea (using xml). I could see three possibilities:
(1) The data for PO printing is pushed in front of Crystal in xml (then Crystal does it's magic and renders the formatted PO print job). Theoretically I guess you could capture an image of the xml data set. Whether it is useful in that form is another question. (I don't how much of PO output is calculated within Crystal.)
(2) I know (depending on how you configured your installation) printed reports are retained for a defined archive period (and viewable/reprintable from system monitor).
The question is - in the case of POs (a Crystal report) - is it the xml being retained and re-rendered as requested - or is it another format being stored (perhaps an image of the print job itself - since non-Crystal reports are also retained for the defined archive period)?
I kind of doubt the archived print jobs are retained in xml form but really have no idea. (Certainly worth checking.)
(3). When you get down to it, a PO's multi-table record structure is quite simple. (Certainly much less complex than a Job's.)
For pure data sharing/transfer purposes, I wouldn't think it would be a big deal at all to write a BAQ that would return all the necessary data that defines (or parts of a PO - as in a PO change request). The BAQ export process will export either to xml or csv files. That just leaves the challenge of developing a dashboard (to allow selection of specific POs) and somehow tying that into the proper BAQ export BO method to generate the xml.
Pretty neat (EDI on the cheap) if you can get it working somehow.
Any ideas out there on how to do something like that?
Rob
Wow. That's a pretty neat idea (using xml). I could see three possibilities:
(1) The data for PO printing is pushed in front of Crystal in xml (then Crystal does it's magic and renders the formatted PO print job). Theoretically I guess you could capture an image of the xml data set. Whether it is useful in that form is another question. (I don't how much of PO output is calculated within Crystal.)
(2) I know (depending on how you configured your installation) printed reports are retained for a defined archive period (and viewable/reprintable from system monitor).
The question is - in the case of POs (a Crystal report) - is it the xml being retained and re-rendered as requested - or is it another format being stored (perhaps an image of the print job itself - since non-Crystal reports are also retained for the defined archive period)?
I kind of doubt the archived print jobs are retained in xml form but really have no idea. (Certainly worth checking.)
(3). When you get down to it, a PO's multi-table record structure is quite simple. (Certainly much less complex than a Job's.)
For pure data sharing/transfer purposes, I wouldn't think it would be a big deal at all to write a BAQ that would return all the necessary data that defines (or parts of a PO - as in a PO change request). The BAQ export process will export either to xml or csv files. That just leaves the challenge of developing a dashboard (to allow selection of specific POs) and somehow tying that into the proper BAQ export BO method to generate the xml.
Pretty neat (EDI on the cheap) if you can get it working somehow.
Any ideas out there on how to do something like that?
Rob
--- On Thu, 12/4/08, Karl Dash <dashkarl@...> wrote:
From: Karl Dash <dashkarl@...>
Subject: Re: [Vantage] Vendor PO Notifications
To: vantage@yahoogroups.com
Date: Thursday, December 4, 2008, 4:20 PM
Robert,
I agree with you on the avoidance of the Vantage products. I can't contact my CAM without the solution costing $20K and up. Currently we email a pdf of the PO which can't be easily edited versus getting, XML files of the PO itself. The pdf needs to be re-keyed by the supplier and they are looking for a more efficient process from us. *Theoretically* if I could grab all of the XML files from each buyer's subdirectory off mfgsysdata, separate them by recipient and email them (or FTP), the supplier would just need to map the files to their system requirements.
Â
-Karl
--- On Thu, 12/4/08, Robert Brown <robertb_versa@ yahoo.com> wrote:
From: Robert Brown <robertb_versa@ yahoo.com>
Subject: Re: [Vantage] Vendor PO Notifications
To: vantage@yahoogroups .com
Date: Thursday, December 4, 2008, 12:25 PM
Karl,
Seem to me EDI has bigger bang for the buck on the supplier side (elimination of an order entry task) versus the buyer side (where you still have to enter POs... They are just transmitted and responded to via EDI - saving some maintenance time at best).
Vantage offers a supplier web portal-ish product. I know nothing about it. I just remember seeing it briefly during a demo two years ago. I wouldn't buy anything from Epicor based on a sales demo any way. Their demos are scripted to avoid revealing problematic areas of applications. (I don't blame them - they are good at it... I just no longer trust them.) I'd have to visit a user site before investing in it.
When money IS an object (and when is it not?) - direct to Fax printing is about as simple as it gets. The better products even act as an archiving process of what was faxed and when.
Rob
--- On Thu, 12/4/08, Karl Dash <dashkarl@yahoo. com> wrote:
From: Karl Dash <dashkarl@yahoo. com>
Subject: [Vantage] Vendor PO Notifications
To: "Vantage Group" <vantage@yahoogroup s .com>
Date: Thursday, December 4, 2008, 10:11 AM
When we went live with Vantage a couple of years ago we proceded with sending out Purchase Orders to our vendors via fax as had been done years before I arrived here. We didn't purchase the EDI module. We are a contract electronics manufacturer and are looking for a way to use technology to remove the manual faxing process. The question is: What processes do YOU use to get the PO's to your suppliers (and invoices back?). Do you rely on a big-bucks bolt-on from Vantage or a third-party technology?
Â
I'm looking for ideas on what works best in a market where money IS a cosideration.
Â
Many, many thanks for your consideration
-Karl
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]