From 5a3acad68e74a55640e29ec84848abb8f44b8516 Mon Sep 17 00:00:00 2001 From: atz Date: Wed, 15 Sep 2010 05:25:00 +0000 Subject: [PATCH] Update README git-svn-id: svn://svn.open-ils.org/ILS/trunk@17682 dcc99617-32d9-48b4-a31d-7c20da2025e4 --- Open-ILS/src/edi_translator/README | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/Open-ILS/src/edi_translator/README b/Open-ILS/src/edi_translator/README index 146bd499d..6c070fdf0 100644 --- a/Open-ILS/src/edi_translator/README +++ b/Open-ILS/src/edi_translator/README @@ -26,7 +26,7 @@ components (on debian lenny linux). There is no such thing (yet?) as "push" from a vendor of their EDI responses. Basically they just put responses in an FTP directory somewhere that you are expected to check. It would be cool if there were a better way to do that like consuming some RSS feed or -remote API callbacks. +remote API callbacks. Similarly, nobody seems willing to utilize interactive EDI. Evergreen will only support one delivery address per PO. That limitation is based on the mapping to the delivery address via the ordering_agency org_unit. If items @@ -36,10 +36,5 @@ If we want to support multiple vendor profiles, then we drop the unique constrai on SAN, add a new one on SAN + profile_code. Profile code then goes in the template. The template logic could get rather complex to support all the optional data elements. -mbklein says: -'order' mapper won't work for EDIFACT versions later than D.96A, because of a change -to the structure of the BGM segment. But as long as all the supported vendors will -accept a D.96A ORDERS (which I think they do), that's not a problem. - SEE ALSO: http://github.com/mbklein/openils-mapper -- 2.11.0