Thoughts on structure for sending different Order formats to suppliers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Thoughts on structure for sending different Order formats to suppliers

BJ Freeman
In the supplier (PO) ordering, I would like to come up with a way
consistent with the svn to designate different ordering formats and
sending protocols.

Some require XML format FTP'd, Some HTML in the body of the email.
Others use the EDI with VANS.

I was thinking of something alone the lines of the Product Store Email
configuration page.

Like expand that page to communication, instead of emails only and
create more types. Possibly under Communications Events.

There would be extra fields in the Entity for protocol to use.

The actual data specific to the Supplier's form of communication would
be associated with party threw the ContactMech

Any Thoughts?

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on structure for sending different Order formats to suppliers

davidnwelton
> Some require XML format FTP'd, Some HTML in the body of the email.
> Others use the EDI with VANS.

Certainly something that's necessary for many businesses.  If I were
using OFBiz, I'd probably be ok with specifying a custom service or
something to send data, and then writing some code to do so.

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on structure for sending different Order formats to suppliers

BJ Freeman
Thanks David:
yes custom code would be in certain circumstances.
But I see some common code for the setup.
Like there is an FTP service now in ofbiz, but it is not implemented at
a higher level.
There is some code for creating xfo documents for emails. So like that
put in code for creating XML and EDi orders, using the same type of UI.


David Welton sent the following on 10/3/2006 3:53 AM:
>> Some require XML format FTP'd, Some HTML in the body of the email.
>> Others use the EDI with VANS.
>
> Certainly something that's necessary for many businesses.  If I were
> using OFBiz, I'd probably be ok with specifying a custom service or
> something to send data, and then writing some code to do so.
>
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on structure for sending different Order formats to suppliers

David E Jones-2
In reply to this post by davidnwelton

On Oct 3, 2006, at 11:53 AM, David Welton wrote:

>> Some require XML format FTP'd, Some HTML in the body of the email.
>> Others use the EDI with VANS.
>
> Certainly something that's necessary for many businesses.  If I were
> using OFBiz, I'd probably be ok with specifying a custom service or
> something to send data, and then writing some code to do so.

Yeah, the first step would be to get some services in place for this  
sort of thing, and that would be useful to a lot of people. How those  
services are configured or deployed would depend on the use case for  
each. Configuring on the store might make sense, but just adding a  
scheduled service to the job sandbox might also make sense...

-David
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on structure for sending different Order formats to suppliers

BJ Freeman
I agree, I was hoping to make the configuration of each of the services,
thru the UI, so they could be done like the email services.
any comments on that?


David E Jones sent the following on 10/3/2006 4:41 AM:

>
> On Oct 3, 2006, at 11:53 AM, David Welton wrote:
>
>>> Some require XML format FTP'd, Some HTML in the body of the email.
>>> Others use the EDI with VANS.
>>
>> Certainly something that's necessary for many businesses.  If I were
>> using OFBiz, I'd probably be ok with specifying a custom service or
>> something to send data, and then writing some code to do so.
>
> Yeah, the first step would be to get some services in place for this
> sort of thing, and that would be useful to a lot of people. How those
> services are configured or deployed would depend on the use case for
> each. Configuring on the store might make sense, but just adding a
> scheduled service to the job sandbox might also make sense...
>
> -David
>