-
Allocation rules should work on revaluation currency process
Foreign currency gain/loss accounting entries are posted to adjust the accounting and reporting currency amounts. These entries should be subject to allocation rules, despite their "currency value" field is 0.00 so that we have a more accurate distribution of the allocated amounts.
-
Subscription revenue split should allow defining discounts or changing the billing amount when the allocation method is set to percentage
Allowing the subscription revenue split to define discounts or change the billing amount when the allocation method is set to percentage would provide greater flexibility and accuracy in financial management. This feature would enable businesses to offer tailored discounts to their customers, enhancing customer satisfaction and loyalty. Additionally, it would allow for more precise billing adjustments, ensuring that revenue allocation aligns perfectly with the company's financial strategies and goals. Overall, this improvement would streamline the billing process and contribute to more efficient and effective revenue management.
Additionally, the copy schedule under the mentioned parameter should work as expected.
Thank you in advance.
-
Supplier transactions that do not affect a tax code should appear in the electronic format exogena 1001
There are multiple petty cash expenses without taxes. Including non-taxable tax codes in the capture of these operations to ensure they are issued in the exógena1001 format requires an increase in manual work.
-
In the Excel Add-In, the design does not include columns to map the fields for project category, project date, and line property
When using the Add-In in a vendor invoice journal where the offset account type is Project, it is required to fill in the fields Category, Project Date, and Line Property. However, the design does not include columns to map these fields.
-
Extension of Financial Dimension Assignment Logic Based on Customer-Invoice Relationship
Currently, the system pulls financial dimensions from the customer account, even when the invoice account represents an intercompany partner. This causes inconsistencies and requires manual adjustments in sales orders.
Identified Scenarios
- Customer via Intercompany Partner: The invoice account represents the partner, but dimensions are pulled from the customer.
- Direct Customer: Same customer can come directly with different subscription.
Issue
When the customer comes through an intercompany partner, the financial dimensions of the partner are not applied correctly, leading to significant manual work.
Proposed solution:
- Detects when the invoice account differs from the customer account.
- If different, and the invoice account is an intercompany partner, automatically assigns financial dimensions from the invoice account.
- If both accounts match, retains the standard behavior.
-
Enhance Dynamic Tax Calculation for Non-Receipted Purchase Orders
Currently, the system does not dynamically adjust the tax portion of committed costs when partial invoicing occurs for purchase orders without receipts. While no direct configuration was found to change this behavior, internal documentation and prior case handling suggest that this is standard system logic.
We propose an enhancement that allows the committed cost calculation to reflect tax adjustments based on the invoiced amount, even when receipts are not involved. This would improve financial accuracy and provide better visibility into actual commitments in scenarios involving partial invoicing.
Expected Benefits:
- More accurate committed cost calculations.
- Improved financial tracking for partially invoiced POs.
- Reduced accounting discrepancies in non-receipted scenarios.
-
Unexpected Validation Behavior with Exclusion Words in file filters Invoice Capture setup
Invoice capture, file filters applied at the file name level are ineffective because the AI also analyzes the document body content.
Based on its name, the expectation is that exclusion words would be validated only against the file name. However, we’ve observed that the validation process is also scanning the document’s content. If an exclusion word is found within the body of the document—even if it’s not present in the file name—the document is rejected.
This behavior contradicts the intended functionality and can lead to unnecessary rejections. It would be beneficial to either restrict the validation strictly to the file name or provide configuration options to control whether content should be scanned.
-
Include the financial dimensions information in General ledger and Journal LATAM reports.
It is suggested that the General Ledger and Journal reports include a column with information on Financial Dimensions.
The SII does require additional information that the company must submit in the so-called “Sworn Statements xxx.” That is, for the columns requested in the sworn statement—whether related to salaries, withholdings, or others—the SII imposes requirements on what information such records should contain, so that by March this information is readily available and can be entered into the corresponding Sworn Statement.
-
The payment schedule of a confirmed sales order in Projects does not carry the information over to the invoice proposal
A team of users is responsible for creating the sales order (SO), filling in the payment schedule, and confirming it.
Later, a different team—separate from the one that generates the sales orders—handles the creation of invoice proposals.
However, when the invoice proposal is created, the payment schedule button is disabled (grayed out).
If the payment schedule information from the confirmed sales order is not automatically transferred, this results in manual rework and adjustments, increasing the risk of errors and inconsistencies.
-
Align Workflow Approval with Printed Journal Header
Description:
Currently, the “Approved by” field in the header of the printed general journal report is only populated when the approval checkbox is enabled in the journal name setup. This disables the use of workflow approval, which many customers rely on for compliance and operational control. As a result, journals approved via workflow do not reflect the approver in the printed report header, leading to confusion and audit challenges.
Problem Identified:
The workflow approval updates the approver field in the
LedgerJournalTrans
table, but not in theLedgerJournalTable
header. The SSRS report (LedgerJournalDP
) only queries the header, resulting in missing approver data even when the journal has been properly approved via workflow.Proposed Improvement:
Update the SSRS report logic to fallback to the
LedgerJournalTrans.Approver
field whenLedgerJournalTable.Approver
is empty. Alternatively, enhance the workflow process to populate the header field upon successful approval.Justification:
- Ensures consistency between approval processes and printed documentation
- Improves audit readiness and traceability
- Reduces support cases related to missing approval data
Expected Impact:
- Clearer printed reports for journals approved via workflow
- Better alignment between system behavior and customer expectations
- Enhanced support for compliance and internal controls