Bots example plugins

There is a lot of useful plugins which are available for download as ZIP files from our Bots Plugins repository Package registry. You can use them to learn the features of Bots and to bootstrap your mappings.

These plugins were created Henk-Jan Ebbers and other members of Bots community.

Demo plugins
- my_first_plugin
  
  Input: EDIFACT ORDERS.
  
  Output: fixed records.
  
  This simple plugin is used in the the Quick Start Guide.
- composite_route
  
  Demonstrates the use of composite routes.
  
  2 different sources are used for incoming EDIFACT files.
  
  Convert EDIFACT orders to fixed format.
  
  Also converts these orders to print format (HTML).
  
  Converts EDIFACT SLSRPT to CSV format.
  
  All outgoing messages go to different destination using filtered outchannels.
- working_with_partners
  
  Demonstrates the use of partner dependent functionalities in bots:
  
  partner dependent translations,
  
  user of ‘default translation’ and imports,
  
  partner dependent syntax,
  
  use of partner-lookup in the database,
  
  use of partner groups,
  
  different destinations/out-channels for partners,
  
  advanced usage of ISA qualifiers/partnerID. Your partnerID is used to lookup the ediID and ISA qualifier in database (and of course vice versa).
- communication_script
  
  Demonstrates the use of communication scripting.
  
  Incoming EDI messages can be passed one by one or as one batch.
- mdn_confirmations
  
  Demo configuration for MDN (email confirmations)
  
  See also documentation about confirmations.
- edifact_orders_to_print
  
  Translates a EDIFACT ORDERS D96A message into a human readable format (HTML).
  
  Of course you can print the output or create a PDF of it, so it’s something like an EDI-to-paper.
- database_communication
  
  Demonstrates database communication scripts; both reading and writing (in separate routes).
  
  A test database comes with the plugin.
- preprocessing
  
  This plugin demonstrate preprocessing: the incoming EDIFACT files start with a number of ‘#’ and ‘@’ characters, which are removed when preprocessing the files.
- xml_enveloping
  
  Converts an EDIFACT D96A INVOIC to XML.
  
  Adds an XML envelope with sender and receiver using envelopescript.
- alto_separate_headers_details
  
  Input: 2 CSV files, one with headers, one with details lines.
  
  This is processed into one idoc (so the headers and details are merged).
  
  Same technique is also usable for fixed format.
- one-on-one_edifact_order_xml
  
  Translates an EDIFACT ORDERS D96A message to XML message using EDIFACT tags as XML elements and vice versa.
  
  Good for those who like processing XML instead of EDIFACT.
  
  It is quite easy to add other EDIFACT messages types for similar translations.
- sap_idoc_orders_WPPLU
  
  EDIFACT D96A ORDERS to idoc ORDERS01.
  
  EDIFACT D96A PRICAT to idoc WP_PLU02.
  
  idoc ORDERS01 to EDIFACT D96A ORDERS.
  
  idoc WP_PLU02 to EDIFACT D96A PRICAT.
EDIFACT plugins
- edifact_to_xml_orders-desadv-invoice
  
  The most often used EDIFACT messages in one package.
  
  Purchase orders: EDIFACT ORDERS to XML.
  
  ASN/shipping list: XML to EDIFACT DESADV.
  
  Invoice: XML to EDIFACT INVOIC.
- edifact_to_fixed_orders_desadv_invoice_aperak
  
  The most often used EDIFACT messages in one package.
  
  Suited for Dutch non-food retailers; probably for a lot of other retailers as well.
  
  EDIFACT ORDERS to fixed file format.
  
  Generate an EDIFACT APERAK - confirmation message (if requested in the order).
  
  Fixed format ASN/shipping list to a EDIFACT DESADV.
  
  Fixed format invoice to EDIFACT INVOIC.
- edifact_to_json_invoice
  
  Translates EDIFACT D96A invoice to JSON and vice versa.
- edifact_orders_to_csv_and_vv
  
  Translates EDIFACT D96A ORDERS to CSV and vice versa.
  
  There a 2 variants: CSV with or without record tags (CSV from eg. Excel is often without records tags).
- edifact_pricat_slsrpt
  
  CSV to EDIFACT PRICAT.
  
  EDIFACT SLSRPT to CSV.
  
  Input CSV files contain spaces which should be stripped (strip_value = True in syntax definition).
X12 plugins
- x12_837_4010_to_837_5010
  
  Converts (physician) insurance claims (x12 837) from the old version 4010 to the new 5010 version.
  
  The mapping file is rudimentary, but I believe the conversion is OK.
  
  I found that removing the one REF file creates a version 5010 file that is accepted and processed properly by Anvicare, the clearing house for my commercial claims.
  
  I have included anonymized input EDI transactions for Medicare, Blue Shield and commercial insurers.
  
  My approach is to try the translation as is, and to make corrections in the mapping file only if I get errors from the clearing house.
  
  Medicare and Blue Shield provide comprehensive error checking function.
  
  The clearing house accepts 5010 transactions, and they work.
- x12_fixed_to_810
  
  Converts fixed inhouse to x12 810 including calculation of invoice totals etc. and partner specific separators.
- x12_to_xml_one-on-one_835-837
  
  Translate x12 835 -> XML and reverse (XML -> x12 835).
  
  translate x12 837 -> XML and reverse (XML -> x12 837).
  
  One-on-one mapping: structure of XML is similar to structure of x12.
  
  x12 envelopes are included in mapping.
- x12_to_xml_retailer_version_850-856-810-997
  
  The most used x12 messages in one package:
  
  translate XML orders -> x12 850.
  
  translate x12 856 -> XML ASN’s
  
  translate x12 810 -> XML invoices
- x12_to_xml_supplier_version_850-856-810-997
  
  The most used x12 messages in one package.
  
  translate x12 850 -> XML orders.
  
  Generates 997’s for the received orders.
  
  translate XML ASN’s -> x12 856; including partner specific translation to 856.
  
  translate XML invoices -> x12 810.
- x12_to_xml_850-856-810-997
  
  A variant of x12_to_xml_supplier_version_850-856-810-997 plugin (above).
- x12_xml_to_850
  
  Simple mapping from x12 850 to XML.
Tradacoms plugins
- tradacoms_to_xml_orders
  
  Simple TRADACOMS example.
  
  Translation from tradacoms orders to XML and from XML orders to tradacoms.