Compare with Purchase Order
Combined Price of Quantity Difference
Purpose:
This workflow card evaluates the combined price of a quantity difference, comparing it against a specified value. It helps automate actions based on price and quantity discrepancies across related documents, improving procurement and receiving workflows. Version 4 expands this functionality by allowing comparisons between different entities such as the purchase order, received quantities, and the document itself, adding more flexibility and control to the workflow.
Components of the Card:
Operator:
Description: The condition for comparing the combined price against a specified value.
Options:
Equals (=): Checks if the combined price matches the specified value.
Not Equals (≠): Ensures the combined price is different from the specified value.
Greater Than (>): Verifies if the combined price is greater than the specified value.
Greater or Equals (≥): Checks if the combined price is greater than or equal to the specified value.
Lesser Than (<): Verifies if the combined price is less than the specified value.
Lesser or Equals (≤): Checks if the combined price is less than or equal to the specified value
Value:
Description: Specifies the value against which the combined price of quantity value will be compared.
Detail: The value has to be a numeric value.
Additional Components in Version 4:
Comparison Type: Selects the entities to compare. The options include:
Purchase Order to Document: Compares the quantities and prices between the purchase order and the related document.
Received to Document: Compares the received quantities to the quantities in the document.
Purchase Order to Received: Compares the purchase order quantities to the received quantities.
Functionality:
Condition Evaluation: Calculates the combined price by multiplying the quantity difference by the price per unit and compares it against the specified value using the selected operator. Version 4 adds the option to compare additional entities based on the user’s configuration, such as purchase order to received or purchase order to document.
Action Execution: Based on whether the combined price meets the specified condition, the workflow will continue with true or false conditions to trigger actions or halt the workflow. Version 4 also allows for more dynamic action execution, where the condition type (e.g., purchase order to received) influences the next step.
Setup and Configuration:
Version 3: Users configure the card by selecting the document fields for the quantity difference and price per unit. The operator is then chosen to define how the combined price will be compared to the specified value. Finally, users set the continue condition (true or false), which dictates the next step in the workflow.
Version 4: In addition to the configuration in Version 3, users have an additional option to configure the Comparison Type. This defines what entities will be compared, such as Purchase Order to Document, Received to Document, or Purchase Order to Received.
Example Scenario:
An invoice shows 50 units of a product at $100 each, totaling $5000. The related purchase order authorized a purchase of $4500 for 45 units. The quantity difference is 5 units, and the combined price of the difference is $500. The card compares the purchase order quantity (45 units) to the received quantity (50 units) and checks if the combined price is greater than $400 (the specified value). Using the Greater Than (>) operator, the card identifies the discrepancy and flags it for review by the finance team.
Conclusion:
Version 3 of the "Combined Price of Quantity Difference" workflow card offers a straightforward approach for comparing quantity discrepancies and triggering actions based on price thresholds. Version 4 extends this functionality by allowing comparisons between different entities (purchase order, received, document), providing more flexibility and control over the workflow. Organizations can now automate more complex scenarios and enforce tighter control over their procurement and receiving processes.
Unit Price Combined with Fields
Purpose:
This workflow card is designed to evaluate whether the unit price, when combined with a specified field value (such as quantity, discount, or additional charges), meets a defined condition. The card compares the unit price and field value to a specified threshold to help ensure that pricing aligns with expectations. This comparison can trigger actions based on specific conditions, such as flagging discrepancies or automating approval processes in procurement or receiving workflows.
Components of the Card:
Field Name
Description: Specifies the document field that contains the value to be combined with the unit price.
Detail: This must match the exact identifier of the first field within the document.
Operator
Description: Defines the condition that will be applied to the comparison between the combined value and the specified value.
Options:
Equals (=): Checks if the combined value of the unit price and field matches the specified value.
Not Equals (≠): Ensures the combined value of the unit price and field is different from the specified value.
Greater Than (>): Verifies if the combined value is greater than the specified value.
Greater or Equals (≥): Checks if the combined value is greater than or equal to the specified value.
Lesser Than (<): Verifies if the combined value is less than the specified value.
Lesser or Equals (≤): Checks if the combined value is less than or equal to the specified value.
Value
Description: Specifies the value against which the combined unit price and field value will be compared.
Detail: The value has to be a numeric value.
Functionality:
Condition Evaluation: The system evaluates the combined unit price and field value based on the selected operator and compares it to the specified value. The result of this evaluation determines whether the condition is true or false.
Action Execution:
True Condition: If the comparison results in true (e.g., the combined value exceeds the specified value), the workflow proceeds with the true condition. This might trigger actions such as approval, document routing, or applying processing rules.
False Condition: If the comparison results in false (e.g., the combined value does not meet the condition), the workflow proceeds with the false condition. This could trigger a notification, send the document for manual review, or stop the workflow.
Setup and Configuration:
Users begin by selecting the document field(s) that contains the value(s) to be combined with the unit price. After selecting the field, they then choose the appropriate operator to define how the combined value will be compared to the specified value. Then they can set the value.
Example Scenario:
An invoice lists 50 units of a product at $20 each, totaling $1000. The related document has a quantity field with a value of 10. Using the "Greater Than" operator, the card compares the combined value of the unit price ($20) and the quantity (10), which equals $200. The card checks if the combined value is greater than $150 (the specified value). Since the combined value of $200 is greater than the threshold of $150, the workflow proceeds to trigger an approval for the document.
Conclusion:
The "Unit Price Combined with Fields" workflow card ensures that pricing conditions are met by evaluating the combined value of the unit price and a specified field. By automating this comparison, organizations can ensure consistency and flag discrepancies in pricing or quantities before proceeding with approval, helping to streamline procurement and financial processes.
Promised Delivery Date on Purchase Order
Purpose
This DocBits card is designed to facilitate the precise comparison of promised delivery dates on purchase orders with delivery dates specified for line items in a table. By integrating a tolerance value, the card ensures flexibility in monitoring delivery timelines, helping maintain inventory planning accuracy and customer satisfaction.
Components of the Card
Operator
Description: Defines the condition applied to compare delivery dates.
Options:
Equals (=): Checks if the promised delivery date on the line item matches the purchase order’s delivery date.
Not Equal (≠): Ensures the promised delivery date on the line item does not match the date on the purchase order.
Greater Than (>): Verifies if the line item’s promised delivery date is later than the purchase order’s delivery date.
Greater or Equals (≥): Checks if the line item’s promised delivery date equals or is later than the purchase order’s delivery date.
Less Than (<): Confirms if the line item’s promised delivery date is earlier than the purchase order’s delivery date.
Less or Equals (≤): Validates if the line item’s promised delivery date equals or is earlier than the purchase order’s delivery date.
Value
Description: Specifies an allowable margin of error in the delivery date comparison.
Detail: Users define the number of days by which the line item delivery date can differ from the promised delivery date.
Functionality
Condition Evaluation: The card calculates the difference between the purchase order's promised delivery date and the delivery dates for line items in the table. The selected operator is then applied to determine if the condition is met.
Action Execution:
True Condition: If the delivery date difference is within the tolerance range and matches the condition set by the operator, the workflow proceeds.
False Condition: If the condition is not met, the workflow will not continue.
Setup and Configuration
The operator is selected to define the desired comparison condition, such as equal to, greater than or less than. Finally, users specify a tolerance value in days, which allows for small variations in the comparison without triggering alerts.
Example Scenario
A purchase order specifies a promised delivery date of December 1st. A line item in the table has a promised delivery date of December 3rd. With a tolerance value set to 2 days and the Equals (≥) operator selected, the card considers the delivery date within the acceptable range. No alert is triggered, ensuring minor variances are tolerated without disrupting operations.
Conclusion
The "Promised Delivery Date Comparison" card helps streamline supply chain operations by enabling precise monitoring of delivery timelines. With its ability to incorporate tolerances and flexible comparison operators, it ensures adherence to delivery expectations while avoiding unnecessary alerts for minor deviations. This enhances vendor management and overall workflow efficiency.
Order Data in Order Confirmation
Purpose
This workflow card is designed to compare specific fields—Unit Price, Discount, or Quantity—between an order confirmation and a purchase order. It ensures consistency and compliance with agreed terms. Based on the comparison result, the card allows users to write specified text into a chosen field when the condition evaluates as true or false, streamlining document processing and reducing manual intervention.
Components of the Card
Order Data
Description: Specifies the field to be compared between the order confirmation and the purchase order.
Options:
Unit Price: Compares the unit price in both documents.
Discount: Compares the discount percentage or value.
Quantity: Compares the ordered quantity.
Operator
Description: Defines the condition applied during the comparison.
Options:
Equals (=): Checks if the value in the selected field matches between the order confirmation and the purchase order.
Not Equals (≠): Ensures the value in the selected field differs between the two documents.
Text
Description: Specifies the text to be written into the target field upon condition evaluation.
Detail: This text can include custom notes, status updates, or predefined values.
Field Name
Description: Specifies the field where the text will be written.
Detail: The target field is selected from available editable fields within the system.
Condition Result
Description: Determines when the text should be written, based on the comparison result.
Options:
True: Writes the text if the comparison condition is met.
False: Writes the text if the comparison condition is not met.
Functionality
Comparison Evaluation: The system compares the selected field between the order confirmation and the purchase order using the specified operator.
Action Execution: If the condition evaluates as true or false, the specified text is written into the designated field.
Setup and Configuration
To set up this card, users first select the field to be compared—Unit Price, Discount, or Quantity. Then, they choose an operator to define the comparison condition, such as equals or not equals. Users specify the text to be written into a target field and select when this action should occur, based on the condition result (true or false).
Example Scenario
An order confirmation lists a unit price of $50 for a product, while the purchase order specifies a price of $45. Using the Not Equals (≠) operator, the card identifies the discrepancy and writes the text "Price Mismatch" into a designated field when the condition evaluates as true.
Conclusion
The "[Unit Price/Discount/Quantity] in Order Confirmation" workflow card provides a practical solution for ensuring document consistency. By automatically flagging discrepancies and writing relevant text into specified fields, it enhances efficiency and reduces errors in order management processes.
Confirmed Delivery Date
Purpose
This workflow card is designed to verify that confirmed delivery dates on invoices or shipping documents align with the accepted delivery dates defined in a master data lookup table. By comparing these dates, it helps ensure compliance with agreed delivery schedules and enhances supply chain reliability.
Components of the Card
Operator
Description: Defines the condition for comparing the confirmed delivery date to the accepted delivery date.
Options:
Is: Confirms that the delivery date matches the accepted delivery date in the master data.
Is Not: Ensures that the delivery date does not match the accepted delivery date in the master data.
Master Data Table Lookup
Description: Specifies the reference table containing accepted delivery dates for comparison.
Detail: The table is defined by the Master Data Table parameter and may include additional metadata such as order numbers or delivery regions.
Functionality
Date Comparison: The system compares the confirmed delivery date from the invoice or shipping document to the accepted delivery date in the specified master data lookup table.
Action Execution: Based on the comparison result, the card can trigger follow-up actions such as notifications.
Setup and Configuration
To configure this card, users select the field representing the confirmed delivery date in the document and specify the master data lookup table containing the accepted delivery dates. An operator is then chosen to define how the two dates should be compared (e.g., Is or Is Not).
Example Scenario
An invoice lists a confirmed delivery date of June 10th, while the master data lookup table specifies an accepted delivery date of June 15th. Using the Is Not operator, the card flags the discrepancy for review, allowing the logistics team to investigate the cause and adjust schedules accordingly.
Conclusion
The "Confirmed Delivery Date vs. Accepted Delivery Date" workflow card helps organizations maintain adherence to agreed-upon delivery schedules by automating the comparison of confirmed and accepted delivery dates. This proactive approach to delivery management enhances operational efficiency, reduces delays, and fosters better collaboration across the supply chain.
Compare Order Confirmation with Purchase order
Purpose:
This DocBits card is designed to compare a specific order data field—such as quantity, discount, or unit price—between an order confirmation and a purchase order. By allowing a focused comparison of one field at a time, it ensures precision in validating key data points, maintaining order accuracy. Version 4 expands this functionality by allowing comparisons between different entities such as the purchase order, received quantities, and the document itself, adding more flexibility and control to the workflow.
Components of the Card:
Any/All
Description: Determines whether the condition applies to any or all lines in the order confirmation. Options:
Any: The comparison will trigger if the selected field value in any line of the order confirmation matches the corresponding value in the purchase order.
All: The comparison will trigger only if the selected field value in all lines of the order confirmation matches the corresponding value in the purchase order.
Order Data Field
Description: Specifies the data field to be compared between the order confirmation and the purchase order.
Detail: Users can select one of the following fields for comparison:
Quantity: Compares the quantity ordered with the confirmed quantity.
Discount: Validates that the discount in the confirmation matches the purchase order.
Unit Price: Ensures that the unit price in the confirmation aligns with the purchase order.
Operator
Description: Defines the condition applied to the comparison of the selected data field.
Options:
Equals (=): Confirms that the value matches the purchase order.
Not Equals (≠): Ensures the value is different from the purchase order.
Greater Than (>): Verifies that the value exceeds the purchase order’s value.
Greater or Equals (≥): Confirms that the value equals or exceeds the purchase order’s value.
Less Than (<): Checks that the value is below the purchase order’s value.
Less or Equals (≤): Confirms that the value is below or equals the purchase order’s value.
Additional Components in Version 4:
Comparison Type: Selects the entities to compare. The options include:
Purchase Order to Document: Compares the purchase order data with the related document.
Received to Document: Compares the received data (e.g., quantities received) with the document.
Purchase Order to Received: Compares the purchase order data with the received quantities.
Functionality:
Field Comparison: The system compares the selected order data field (Unit Price, Discount, or Quantity) from the order confirmation to the corresponding value in the purchase order.
Action Execution: Based on the comparison result and operator condition, the card can trigger follow-up actions, such as notifications or alerts.
Example Scenario:
An order confirmation specifies a unit price of $50, while the purchase order states $45. Using the "Greater Than" operator, the card flags the discrepancy, enabling the procurement team to address it before processing.
Conclusion:
This card simplifies the validation of individual order data fields, ensuring compliance with purchase order terms. By isolating one field at a time for comparison, it supports targeted reviews and error prevention in order processing.
Tax in document field
Purpose:
This workflow card is designed to evaluate whether the tax value in a document field matches the tax value in a purchase order, considering tolerances based on charge ID. The card compares these two tax values (one from the document field and one from the purchase order) and checks if they meet a specified condition (e.g., equals, greater than, lesser than, etc.). This helps ensure tax values are consistent and flag discrepancies for further review or approval in procurement workflows.
Components of the Card:
Field Name
Description: Specifies the document field that contains the tax value to be compared with the tax value in the purchase order.
Detail: This field must match the exact identifier for the tax value in the document.
Operator
Description: Defines the condition to be applied to the comparison between the document's tax value and the purchase order's tax value.
Options:
Equals (=): Checks if the tax in the document field matches the tax in the purchase order.
Not Equals (≠): Ensures the tax in the document field does not match the tax in the purchase order.
Greater Than (>): Verifies if the tax in the document field is greater than the tax in the purchase order.
Greater or Equals (≥): Checks if the tax in the document field is greater than or equal to the tax in the purchase order.
Lesser Than (<): Verifies if the tax in the document field is less than the tax in the purchase order.
Lesser or Equals (≤): Checks if the tax in the document field is less than or equal to the tax in the purchase order.
Master Data Table
Description: The table that contains the purchase order details, including the charge ID and tax values.
Detail: This table must have a reference to the charge ID associated with the purchase order tax value.
Tolerance Amount
Description: The threshold amount within which the tax values can vary. This is used to account for minor discrepancies in tax calculations.
Detail: The tolerance amount should be a numeric value, defining the maximum allowed difference between the tax values.
Tolerance Type
Description: Specifies the type of tolerance being applied, either absolute or percentage-based.
Options:
Value: The tolerance is a fixed numeric value.
Percentage: The tolerance is calculated as a percentage of the tax value.
Functionality:
Condition Evaluation: The system evaluates whether the tax value in the document field meets the condition specified when compared to the tax value in the purchase order (with the charge ID reference from the master data table). The tolerance amount and type are considered in this evaluation to allow for minor differences in tax calculations.
Action Execution:
True Condition: If the tax in the document field meets the condition when compared to the purchase order's tax (within the tolerance amount and type), the workflow continues.
False Condition: If the tax in the document field does not meet the condition (either not within the tolerance range or the comparison fails), the workflow will stop.
Setup and Configuration:
Users must select the document field that contains the tax value to be compared. They will then choose the operator for how the comparison should be made (e.g., equals, greater than). Following this, users need to specify the master data table reference and set the tolerance amount and type to account for minor tax discrepancies.
Example Scenario:
An invoice lists a tax amount of $100. The corresponding purchase order, found in the master data table, specifies a tax value of $95. Using the "Greater Than" operator, the system compares the document’s tax value ($100) to the purchase order tax value ($95) with a tolerance of $10 (absolute tolerance type). Since the difference of $5 is within the tolerance range, the workflow proceeds without triggering any alerts.
Conclusion:
The "Tax in Document Field Comparison" workflow card ensures that tax values in documents align with purchase order details, allowing for minor discrepancies based on specified tolerances. By automating this check, organizations can minimize errors in tax calculations and streamline procurement processes, reducing the need for manual intervention or approvals.
Any / All Quantity
Purpose:
This workflow card is designed to compare the quantity in a document against the tolerance defined in the purchase order. It allows users to evaluate if the quantity meets certain conditions, such as equality or exceeding the specified tolerance. In Version 4, the card extends functionality by adding the ability to compare multiple entities, including the purchase order, received quantities, and document quantities, offering greater flexibility in handling different scenarios.
Components of the Card:
Any / All:
Description: Specifies how the comparison should be applied across multiple items or conditions.
Options:
Any: At least one of the conditions must be true for the action to be triggered.
All: All conditions must be true for the action to proceed.
Operator:
Description: Defines the condition that will be applied to compare the document quantity against the specified tolerance.
Options:
Equals (=): Checks if the quantity matches the specified tolerance value.
Not Equals (≠): Ensures the quantity is different from the specified tolerance value.
Greater Than (>): Verifies if the quantity is greater than the specified tolerance.
Greater or Equals (≥): Checks if the quantity is greater than or equal to the specified tolerance.
Lesser Than (<): Verifies if the quantity is less than the specified tolerance.
Lesser or Equals (≤): Checks if the quantity is less than or equal to the specified tolerance.
Tolerance Amount:
Description: Specifies the tolerance value that the document quantity will be compared against.
Detail: This value is numeric and represents the threshold of allowed variance in the quantity
Tolerance Type:
Description: Defines the type of tolerance that will be applied.
Options:
Percentage: Tolerance is calculated as a percentage of the purchase order quantity.
Value: Tolerance is specified as a fixed numeric value.
Additional Components in Version 4:
Comparison Type: Selects the entities to compare, providing more flexibility in how the quantities are evaluated in Version 4.
Purchase Order to Document: Compares the quantity in the purchase order to the quantity in the related document.
Received to Document: Compares the received quantity to the quantity in the document.
Purchase Order to Received: Compares the purchase order quantity to the received quantity.
Functionality:
Condition Evaluation: The system compares the quantity in the document against the tolerance in the purchase order based on the selected operator and tolerance amount/type. In Version 4, the Comparison Type allows for different quantities to be compared, such as purchase order to received, or purchase order to document, providing a more dynamic comparison.
Action Execution:
True Condition: If the comparison results in true (e.g., the document quantity is within the acceptable tolerance range), the workflow will proceed.
False Condition: If the comparison results in false (e.g., the quantity does not meet the tolerance), the workflow will not proceed.
Setup and Configuration:
Version 3:
Users configure the card by selecting the document quantity, defining the tolerance amount and tolerance type, and choosing the appropriate operator to compare the quantity against the tolerance. The card evaluates whether the quantity is within the tolerance threshold and proceeds with the "True" or "False" action based on the result.
Version 4:
In addition to the configuration in Version 3, users can select the Comparison Type, allowing comparisons between different entities, such as:
Purchase Order to Document
Received to Document
Purchase Order to Received
Example Scenario:
An invoice shows that 100 units were delivered, but the purchase order only authorized 90 units. The tolerance amount is set at 10 units, and the tolerance type is absolute.
Version 3: The card compares the 100 units in the document against the purchase order's tolerance of 90 units. If the quantity exceeds the tolerance, the card flags the discrepancy for further review.
Version 4: The card could compare the purchase order quantity (90 units) to the received quantity (100 units) or the document quantity (100 units). Depending on the selected Comparison Type, it checks if the difference between the two entities exceeds the tolerance and triggers the corresponding action.
Conclusion:
Version 3: This workflow card compares the document quantity with the purchase order tolerance, helping to ensure that discrepancies in quantity are flagged and handled appropriately.
Version 4: Extends this functionality by allowing users to compare different entities, such as purchase order to received or purchase order to document, providing greater flexibility in handling more complex scenarios. Version 4 ensures tighter control over procurement and receiving workflows, offering more dynamic comparisons and actions based on the chosen comparison type.
Compare Total Charges
Purpose:
This workflow card compares the total charges in a document field with the corresponding charges in a purchase order. The card helps ensure that the charges in the document align with those in the purchase order, considering specified tolerance levels. The comparison can trigger actions if discrepancies are found, such as flagging discrepancies for review or adjusting charges accordingly.
Components of the Card:
Field Name:
Description: Specifies the document field that contains the total charge values to be compared with the charges in the purchase order.
Detail: The value in this field represents the total charges applied in the document (e.g., invoice) and will be compared with the purchase order charge.
Operator:
Description: Defines the condition that will be applied to the comparison between the total charge in the document and the charge in the purchase order.
Options:
Equals (=): Verifies if the total charge in the document matches the charge in the purchase order.
Not Equals (≠): Ensures the total charge in the document is different from the charge in the purchase order.
Greater Than (>): Verifies if the total charge in the document is greater than the charge in the purchase order.
Greater or Equals (≥): Verifies if the total charge in the document is greater than or equal to the charge in the purchase order.
Lesser Than (<): Verifies if the total charge in the document is less than the charge in the purchase order.
Lesser or Equals (≤): Verifies if the total charge in the document is less than or equal to the charge in the purchase order.
Tolerance Amount
Description: Specifies the tolerance threshold for comparing the total charges.
Detail: This numeric value represents the allowed variance in charges between the document and the purchase order.
Tolerance Type:
Description: Specifies the type of tolerance that will be applied.
Options:
Percentage: Tolerance is applied as a percentage of the purchase order charge.
Value: Tolerance is applied as a fixed numeric amount.
Separator:
Description: Specifies the separator used to distinguish the Charge ID at the end of the field name.
Detail: The separator separates the charge field from the unique Charge ID that will be used to link the document charge to the corresponding charge in the purchase order.
Functionality:
Condition Evaluation: The system compares the total charge in the document field with the corresponding charge in the purchase order based on the operator and tolerance. The tolerance is applied to determine whether the difference between the two charges is within an acceptable range.
Action Execution:
True Condition: If the charges match (considering tolerance) and the condition is true, the workflow will continue with the defined action, such as document approval or further processing.
False Condition: If the condition is false (i.e., the charges do not match within the tolerance), the workflow will not continue.
Setup and Configuration:
Users begin by selecting the document field that contains the total charge value. Next, they select the operator to define how the charge will be compared to the purchase order charge. Then, users set the tolerance amount and tolerance type (percentage or absolute). Finally, they specify the separator and Charge ID that will be used for comparison.
Example Scenario:
An invoice lists a charge of $500 in the "total charges" field. The corresponding purchase order charge is $480, and the tolerance is set to $20 (absolute tolerance). The card compares the document charge against the purchase order charge:
The total charge in the document is within the $20 tolerance of the purchase order, and the workflow continues without issue.
If the charge exceeds the tolerance, the workflow flags the discrepancy for review.
Conclusion:
The "Compare Total Charges" workflow card ensures that the charges in documents align with those in purchase orders, considering specified tolerance levels. This helps organizations automate the verification process, identify discrepancies early, and maintain better control over charge-related processes.
Out of Tolerance Unit Price
Purpose:
This workflow card is designed to evaluate whether the combined value of unit prices and a specified field exceeds or falls short of a defined threshold. It helps identify any discrepancies where the unit prices, when combined with other fields, are out of tolerance, ensuring that pricing conditions meet expectations and flagging any issues for review or further action.
Components of the Card:
Field Name:
Description: Specifies the document field that contains the value to be combined with the unit price.
Detail: The value in this field will be combined with the unit price to create the total combined value for comparison.
Operator:
Description: Defines the condition for comparing the combined value of the unit price and the field value against the specified value.
Options:
Equals (=): Verifies if the combined value of the unit price and the field matches the specified value.
Not Equals (≠): Ensures the combined value of the unit price and the field is different from the specified value.
Greater Than (>): Verifies if the combined value of the unit price and the field exceeds the specified value.
Greater or Equals (≥): Verifies if the combined value of the unit price and the field is greater than or equal to the specified value.
Lesser Than (<): Verifies if the combined value of the unit price and the field is less than the specified value.
Lesser or Equals (≤): Verifies if the combined value of the unit price and the field is less than or equal to the specified value.
Value:
Description: Specifies the value against which the combined unit price and field value will be compared.
Detail: This numeric value represents the threshold for comparison. If the combined value of the unit price and field exceeds or falls short of this value (based on the selected operator), the condition will trigger the specified actions.
Functionality:
Condition Evaluation: The system calculates the combined value by multiplying or adding the unit price with the field value, depending on the configuration. The result is then compared to the specified value using the selected operator. If the condition is met (i.e., the combined value is out of tolerance), the workflow proceeds with the next step, whether that’s approval, rejection, or further review.
Action Execution:
True Condition: If the comparison results in true (i.e., the combined value meets the condition), the workflow triggers the action associated with the true condition (e.g., approval or notification).
False Condition: If the comparison results in false (i.e., the combined value does not meet the condition), the workflow will not proceed.
Setup and Configuration:
Users select the field that contains the value to be combined with the unit price. Next, they choose the appropriate operator to determine how the combined value will be compared to the specified value. Finally, the user sets the value that the combined price will be compared to.
Example Scenario:
An invoice lists 50 units of a product at $30 each, totaling $1500. The related document has a quantity field with a value of 10. The combined price is calculated by multiplying the unit price ($30) and the quantity (10), resulting in $300. The card then compares this combined value to a threshold of $250. Using the “Greater Than” operator, the card identifies that $300 is greater than $250, triggering an approval process for the document.
Conclusion:
The "Out of Tolerance Unit Prices Combined with Fields" workflow card helps ensure that pricing and field values are in alignment with business rules. By automating this check, organizations can identify discrepancies early in the process, ensuring that any out-of-tolerance unit prices are flagged for review or necessary action.
Any / All Unit Price is
Purpose:
This workflow card is used to compare the unit price in a document against the unit price in a purchase order, ensuring that prices align within defined tolerance levels. The comparison can trigger actions if the unit price does not meet expectations. Version 4 adds more flexibility by allowing users to choose different entities for comparison, providing a deeper level of control over pricing and procurement processes.
Components of the Card:
Any / All:
Description: Defines whether the condition applies to any or all instances where the unit price is compared.
Options:
Any: The condition is met if any unit price meets the specified comparison condition.
All: The condition is met only if all unit prices meet the specified comparison condition.
Operator:
Description: Defines the condition for comparing the unit price against the specified value.
Options:
Equals (=): Verifies if the unit price matches the specified value.
Not Equals (≠): Ensures the unit price is different from the specified value.
Greater Than (>): Verifies if the unit price is greater than the specified value.
Greater or Equals (≥): Verifies if the unit price is greater than or equal to the specified value.
Lesser Than (<): Verifies if the unit price is less than the specified value.
Lesser or Equals (≤): Verifies if the unit price is less than or equal to the specified value.
Additional Components in Version 4:
Comparison Type:
Description: Allows users to choose what entities will be compared in addition to the unit price.
Options:
Purchase Order to Document: Compares the unit price in the purchase order with the unit price in the document.
Received to Document: Compares the received quantity to the unit price in the document.
Purchase Order to Received: Compares the unit price in the purchase order with the received quantity.
Functionality:
Condition Evaluation: The system compares the unit price in the document to the unit price in the purchase order (or other selected entity, in Version 4) based on the selected operator. If the comparison is true, the workflow proceeds according to the next steps, either triggering approval or stopping the process.
Action Execution:
True Condition: If the condition evaluates to true (e.g., unit price in the document is greater than the specified value), the workflow will proceed with the true action (e.g., approval, document processing).
False Condition: If the condition evaluates to false (e.g., unit price in the document does not meet the comparison), the workflow will not proceed.
Setup and Configuration:
Version 3 Setup: Users configure the card by selecting the unit price in the document, choosing the appropriate operator to define how the unit price will be compared to the specified value, and setting the value to compare against. Additionally, users select whether the condition applies to any or all instances of the unit price comparison.
Version 4 Setup: In Version 4, users have the additional option to select the Comparison Type. This allows them to define the entities to compare, such as Purchase Order to Document, Received to Document, or Purchase Order to Received. This enhances the flexibility of the card to compare unit prices in more complex scenarios.
Example Scenario:
Version 3 Example:
An invoice shows a unit price of $50. The related purchase order has a unit price of $45. The card compares the two unit prices using the "Greater Than" operator. Since the unit price in the document ($50) is greater than the unit price in the purchase order ($45), the workflow will trigger the true condition (e.g., send the document for review).
Version 4 Example: An invoice shows a unit price of $50, and the related purchase order authorized a unit price of $45. Additionally, the received quantity is 60 units. The card compares the received quantity to the document's unit price using the "Greater Than" operator. Since the received quantity (60) is greater than the unit price ($50), the workflow triggers the true condition, and the document is flagged for further review.
Conclusion:
Version 3 of the "Unit Price Comparison" workflow card is designed to ensure that unit prices in documents align with those in purchase orders, triggering actions based on defined conditions. Version 4 extends this functionality by introducing more complex comparison options, such as comparing purchase orders to documents, received quantities to documents, and purchase orders to received quantities. This added flexibility allows organizations to handle more sophisticated pricing and procurement scenarios, improving control and accuracy in their workflows.
Item Id on Purchase Order
Purpose:
This workflow card is designed to compare item IDs between a purchase order and a related document to ensure that the correct items are included. The card evaluates whether the item ID in the purchase order matches the item ID in the document. This comparison can trigger actions if discrepancies are found, ensuring that the items in the document align with the purchase order.
Components of the Card:
Any / All:
Description: Defines whether the condition applies to any or all instances of item ID comparisons.
Options:
Any: The condition is met if any item ID in the purchase order matches the item ID in the document.
All: The condition is met only if all item IDs in the purchase order match the item IDs in the document.
Operator:
Description: Defines the condition for comparing the item ID on the purchase order to the item ID on the document.
Options:
Equals (=): Verifies if the item ID in the purchase order exactly matches the item ID in the document.
Not Equals (≠): Ensures that the item ID in the purchase order does not match the item ID in the document.
Functionality:
Condition Evaluation: The system compares the item ID in the purchase order to the item ID in the document based on the selected operator. If the comparison condition is true (e.g., item IDs match or do not match), the workflow will proceed accordingly.
Action Execution:
True Condition: If the condition evaluates to true (e.g., the item ID in the purchase order equals the item ID in the document), the workflow will proceed with the true action (e.g., approval or further processing).
False Condition: If the condition evaluates to false (e.g., the item ID in the purchase order does not match the item ID in the document), the workflow will not proceed.
Setup and Configuration:
Users configure the card by selecting the item ID in both the purchase order and the document. They then choose the appropriate operator (Equals or Not Equals) to define how the item IDs will be compared. Lastly, users select whether the condition applies to any or all of the item IDs in the comparison.
Example Scenario:
An invoice lists an item with ID "ABC123" and the related purchase order also includes an item with ID "ABC123". Using the "Equals" operator, the card compares the item ID in the document with the item ID in the purchase order. Since the item IDs match, the workflow continues without issue
Conclusion:
The "Item ID Comparison" workflow card ensures that the item IDs in documents align with those in purchase orders. This helps prevent discrepancies in item listings and ensures that the correct items are processed according to the purchase order. The ability to compare based on any or all instances provides flexibility in different use cases, improving the accuracy and efficiency of procurement workflows.
Supplier on Invoice
Purpose:
This workflow card is designed to compare the supplier information on an invoice against the supplier information on the related purchase order. The card ensures that the supplier on the invoice matches the supplier on the purchase order. This comparison helps verify that the correct supplier is invoicing for the order and can trigger actions based on any discrepancies.
Components of the Card:
Operator:
Description: Defines the condition for comparing the supplier on the invoice to the supplier on the purchase order.
Options:
Is: Checks if the supplier on the invoice matches the supplier on the purchase order.
Is Not: Ensures that the supplier on the invoice does not match the supplier on the purchase order.
Functionality:
Condition Evaluation: The system compares the supplier on the invoice to the supplier on the purchase order based on the selected operator. If the comparison condition is true (e.g., the supplier is the same or different as required), the workflow will proceed accordingly.
Action Execution:
True Condition: If the condition evaluates to true (e.g., the supplier on the invoice matches the supplier on the purchase order), the workflow continues without triggering any errors.
False Condition: If the condition evaluates to false (e.g., the supplier on the invoice does not match the supplier on the purchase order), the workflow will not continue.
Setup and Configuration:
Users choose the appropriate operator ("Is" or "Is Not") to define how the suppliers will be compared.
Example Scenario:
An invoice lists a supplier with the ID "SUP123" and the related purchase order also lists "SUP123" as the supplier. Using the "Is" operator, the card compares the suppliers and finds them to be the same, so the workflow proceeds without any issue.
Conclusion:
The "Supplier Comparison" workflow card ensures that the correct supplier is invoicing for the purchase order, helping to prevent discrepancies and errors in the procurement process. By automatically verifying supplier information, organizations can streamline their invoice approval process and reduce the risk of fraud or errors in supplier billing.
Order Type of Purchase Order
Purpose:
This workflow card is designed to compare the order type of a purchase order against a specified value. The card checks whether the order type of the purchase order meets the specified condition (e.g., whether it equals, does not equal, is greater than, or meets another condition) to ensure that the purchase order is classified correctly. This comparison can trigger actions based on specific conditions, such as routing the order for further review or approval if discrepancies are found.
Components of the Card:
Any/All:
Description: Defines whether the condition applies to any or all purchase orders being evaluated in the workflow.
Options:
Any: The condition is met if any one of the purchase orders matches the specified condition.
All: The condition is met only if all of the purchase orders meet the specified condition.
Operator:
Description: Defines the condition that will be applied to compare the order type against a specified value.
Options:
Equals (=): Checks if the order type matches the specified value.
Not Equals (≠): Ensures the order type is different from the specified value.
Order Type:
Description: Specifies the value to which the order type of the purchase order will be compared.
Detail: The value must match the order type or classification in the system.
Functionality:
Condition Evaluation: The system evaluates the order type of the purchase order against the specified condition using the selected operator. If the order type matches (or does not match) the specified value, the workflow proceeds accordingly.
Action Execution:
True Condition: If the condition evaluates to true (e.g., the order type matches the specified value), the workflow will continue, possibly triggering additional actions or processing steps.
False Condition: If the condition evaluates to false (e.g., the order type does not match the specified value), the workflow will not continue.
Setup and Configuration:
Users configure the card by selecting the order type field of the purchase order and choosing the operator that defines how the order type will be compared. Then, they set the specified value and decide whether to apply the condition to any or all of the purchase order lines.
Example Scenario:
A purchase order has the order type "Standard." The workflow is configured to check if the order type is "Urgent." Using the "Equals" operator, the card compares the order type and finds that it does not match the specified value, triggering the workflow to send the order for review due to the mismatch.
Conclusion:
The "Order Type of Purchase Order" workflow card ensures that purchase orders are classified correctly according to their specified order type. By automating the comparison of order types, organizations can ensure that purchase orders are processed according to their expected classifications, helping to enforce compliance and streamline procurement workflows.