Today we're announcing the launch of our lookup data feature. A frequent ask from customers and implementors is the ability to have a "scratch pad" of structured data that they can add to their transactions. With the new lookup data feature, you can now securely store information like product item data, vendor locations, or any other information in our flexible lookup data tables, and then apply this information to your transactions, all in just two easy steps.
Store your data
Create your lookup table by defining key-value data pairs.
Applying the data in the rules engine
Using the new LOOKUPDATA function you can write rules to reference your lookup tables and populate your transactions.
We've made the sign-up process with Orderful easier than ever. After your email has been verified, you can either create a new organization or join an existing one.
Create A New Organization
The process to create a new organization is unchanged – you enter your organization details, such as your organization's name and ISA ID, and your user account is then attached to this brand new organization, ready to start trading with Orderful.
Join An Existing Organization
Simply enter your organization's ISA ID and your account will be joined to this organization.
🚧
Authorized Domain
Your verified email must be from a domain authorized by the organization you wish to join. For example, if you work for Wonka Industries, then your email would have to be something like [email protected] to show you're a member of that organization.
Guidelines now support select X12 versions in addition to the Orderful schema. This will speed up data entry as the guideline layout should map directly to the EDI specifications of a trading partner.
Here's how to add a new guideline for an X12 version:
Go to the Guidelines page
Click the 'New Guideline' button
Choose a direction and transaction type
Choose a version from the available options (options will change for each transaction type)
When you go into a versioned guideline you'll see that it looks very similar to your existing guidelines. The main differences will be in the naming and positioning of certain loops, segments and data elements.
Here's an example highlighting some differences between the Orderful and X12 4010 versions for the ISA (Interchange Control Header) segment:
Introducing the Transaction Print View! Now you can see select transaction types in a familiar format that's easier to read than JSON (for most).
To see the print view, go to a Purchase Order, Purchase Order Change, or Payment. The print view will be visible by default.
To print your transaction, click the 'Print' button. If you'd like to include background colors, you might need to adjust your print settings in your browser's print dialogue menu. If you're using Google Chrome, you can do so under 'More Settings' by checking the 'Background Graphics' option.
If your transaction is Invalid and requires rule changes, or if you prefer viewing your transaction in JSON, simply click the 'Rules Editor' link and you'll be back to Orderful's familiar JSON view.
Changelog
added: Transaction Print View for Purchase Orders
added: Transaction Print View for Purchase Order Changes
Our rules engine has functions to manipulate almost anything – modify text, calculate numbers, use conditional logic, or execute other data changes. But for some truly complex, yet common tasks, that might require stitching together quite a number of functions to get the result you need.
For example, take setting the item status code on the 855 (Purchase Order Acknowledgement). Let's say your trading partner ordered 10 cases of pencils at $10.00 per case. Unfortunately though, your trading partner's information is out of date, so they didn't know the price per case is now actually $10.50. As a result, in the PO Acknowledgement, you need to set the status for the item as 'IP' to signify that the actual price is different from what was specified in the 850 (Purchase Order). This might be a problem if your integrated system of record doesn't store the original 850 as it was received, but instead simply overwrites the price with the new value.
Here's the logic we would need to execute in order to set the item status:
We need to find the original 850
We need to match each line item in the 850 with the corresponding line item in the 855 (extra hard depending on how your trading partner references an item)
We need to compare the price
We need to compare the quantity
We need to compare the units of measure
That's a lot of logic to write for a single element. In fact, with our existing functions, it would take over 60 deeply-nested functions – not something easily done!
Enter the smart rule! With smart rules, we give you the ability to execute pre-written, common EDI tasks in a single line. All of the above can be accomplished with a single function call to SMART("itemStatusCode") as seen below:
Check out the documentation or try it yourself in Orderful today.
Changelog
added: New SMART function
fixed: Turnaround rule business number reference were broken
fixed: Empty guidelines codes always caused a validation error
Orderful transaction schemas contain everything needed to capture X12 EDI data. However sometimes you might want to add your own loosely-formatted data to a transaction and then manipulate it later.
For example you might have an integration that always expects an element called Date to be populated. However you suspect various trading partners could populate it in similar but different elements. Instead of an expensive and time-consuming change to your integration every time you add a new trading partner you could simply create a user defined property called expectedDate and use the rules engine to set that conditionally depending on how your trading partner sets data. That way your integration never changes.
See below to watch how easy it is to set the user defined properties in the UI
Every loop and segment accepts a userDefined element so for outbound transactions you can even define it in your integration before the transaction is created. This might be helpful if you have additional data available in your ERP but you're not sure where to map it during your integration. You can add it to the user defined element and then use the rules engine to retrieve it later if the need arises, once again eliminating the need for a costly code change.
Changelog
added: New SET and OBJECT functions to allow user defined object creation
While the transaction list view in the Orderful UI is a great place to see all your transactions at a glance sometimes some graphical sizzle makes it even easier to know your EDI transactions are flowing correctly. Say no more and prepare to meet our new dashboard.
Overview
The dashboard is a collapsible set of graphs that show easily digestible views of your transaction status and historical distribution at a glance.
Filtering
The dashboard responds to the same filters as the previous list view. For convenience we've added granular date filters.
Contextual Information
Hover your cursor over various parts of the graphs for details
No changes are needed on your part. Chat with an EDI expert to learn more!
We're proud to announce the launch of our new web form feature. Now you can create a new transaction directly in the UI. Whether you want to use it to try out Orderful before you integrate your ERP or you just prefer to key all your transactions by hand, web forms are ready for you.
Forms are based off Orderful transaction types so they're available for any current and future transaction types. Also they're built against your trading partners' guidelines so you'll always be able to enter exactly what you need.
Overview
To start, go the the transaction list and click 'New Transaction'.
Then simply fill out the form and your transaction will be created.
Money isn't everything but it's important. It's worth making sure it's right. So we're introducing the first of a series of decimal/currency based functions to help format currency values.
FIXED
Sometimes your integrated system may produce currency values that look more like decimals like this
However your trading partner expects currency values in the resulting X12 transaction that look like this