Hey there, let's tackle this rounding headache with Mustangproject's XRechnung generation—those cent discrepancies can be such a pain for invoicing accuracy, I totally get it.

First, let's break down why your manual sum settings might not be sticking:

核心问题推测 #

The most likely culprit is the order of operations and the library's internal calculation logic. When you call xInvoice.calculate() first, the library computes all the sums (line totals, VAT, grand total) based on individual line items. Then when you set your custom values, the library might be re-running these calculations silently later—like right before generating the XML output—overwriting your manual inputs.

Another thing to check: some fields in CalculatedInvoice might be marked as "derived" or computed on-the-fly, so setting them directly doesn't persist unless you disable the auto-calculate behavior.

具体解决步骤与调试建议 #

1. 调整代码执行顺序 & 禁用自动计算（如果支持）

Try reversing the order: set your custom sums after running calculate(), but also check if the library has a way to turn off auto-recalculation. For example, some versions have a setAutoCalculate(false) method to lock in your manual values:

void fillSums(CalculatedInvoice xInvoice, InputData invoiceData) {
    // First let the library run initial calculations
    xInvoice.calculate();
    
    // Override with your precomputed values
    xInvoice.setLineTotalAmount(euroPriceOfCents(invoiceData.getInvoiceSubTotal()));
    xInvoice.setGrandTotal(euroPriceOfCents(invoiceData.getInvoiceTotal()));
    xInvoice.setTaxBasis(euroPriceOfCents(invoiceData.getInvoiceTaxBase()));
    xInvoice.setTaxTotalAmount(euroPriceOfCents(invoiceData.getInvoiceTaxValue()));
    xInvoice.setDuePayable(euroPriceOfCents(invoiceData.getInvoiceTotal()));
    
    // Lock in the values if the library supports it
    if (xInvoice instanceof AutoCalculatable) {
        ((AutoCalculatable) xInvoice).setAutoCalculate(false);
    }
}

(Note: Fixed the missing closing parenthesis in your original setDuePayable call—small syntax errors can cause unexpected behavior too!)

2. 手动控制行项目金额（从根源避免偏差）

Instead of fixing the totals after the fact, set each line item's values manually so the library's sum calculation will naturally match your expected totals. This aligns better with how XRechnung expects line-level data to roll up:

void setupInvoiceLines(CalculatedInvoice xInvoice, InputData invoiceData) {
    for (InvoiceLine line : xInvoice.getInvoiceLines()) {
        // Use BigDecimal for all calculations—never float/double!
        BigDecimal quantity = new BigDecimal(line.getInvoicedQuantity().getValue());
        BigDecimal unitPriceInclVat = new BigDecimal("120.00");
        BigDecimal unitVat = new BigDecimal("7.85");
        
        // Set line-level values explicitly
        line.setLineExtensionAmount(unitPriceInclVat.subtract(unitVat).multiply(quantity)); // Excl VAT
        line.setTaxAmount(unitVat.multiply(quantity)); // Exact VAT per line
        
        // Ensure the unit price is set to your precomputed value (incl VAT if needed)
        line.setPrice(unitPriceInclVat);
    }
    
    // Now calculate totals—they should match your expected values
    xInvoice.calculate();
}

3. 验证金额转换方法

Double-check your euroPriceOfCents method to make sure it's converting cents to euros correctly using BigDecimal. A common mistake is using integer division or floating-point conversion, which introduces precision loss:

// Correct implementation example
private BigDecimal euroPriceOfCents(long cents) {
    return new BigDecimal(cents).divide(new BigDecimal(100), 2, RoundingMode.HALF_UP);
}

4. 调试XML生成前的状态

Add a debug step right before generating the XML to print out the CalculatedInvoice's field values. If they show your manual sums here but the XML has wrong values, the library is definitely recalculating during serialization. In that case, you might need to bypass the calculate() method entirely and set all required fields manually.

额外注意事项 #

• XRechnung Compliance: Make sure manually setting totals doesn't violate XRechnung schema rules—some fields are required to be derived from line items. If compliance is critical, you might need to adjust your line item calculations to ensure the roll-up matches your desired totals exactly.
• Check Library Version: Older versions of Mustangproject might have bugs with manual sum overrides. Updating to the latest stable release could resolve the issue.

If you try these steps and still hit roadblocks, let's dive deeper into the library's internals or check if there's a specific configuration we're missing! 😊