Closed mimy2001 closed 9 months ago
Attention: 4 lines
in your changes are missing coverage. Please review.
Comparison is base (
b631573
) 73.74% compared to head (e1c8787
) 73.61%.:exclamation: Current head e1c8787 differs from pull request most recent head f5d4d03. Consider uploading reports for the commit f5d4d03 to get more accurate results
Files | Patch % | Lines |
---|---|---|
pkg/batch/batch.go | 0.00% | 4 Missing :warning: |
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Thanks for this fix! It looks like Go will use scientific notation because the XML spec supports it but obviously FinCEN doesn't. Are there other float64 fields to make this fix for too?
@adamdecaf I only noticed it with total amount, but technically this could happen for any other float64 fields. Do you want me to also see if I should make this fix elsewhere as well? And that's right, go uses scientific notation due to XML, if this was json we wouldn't have an issue. Even though XML spec supports this, fincen doesn't, we tried this and it failed with errors.
Yea, this change is fine. I see maybe one other spot to fix this.
@mfdeveloper508 Do you know why we copied in some code from Go's repository? Why do we have a copy of their xml marshaling? https://github.com/moov-io/fincen/blob/3fce8e831a869617e511b94f3d264ba1b03fe60c/marshal.go#L915-L916
Edit: If I remove our copy of MarshalIndent no tests fail, so why was it needed?
@adamdecaf I just realized something, the fix I need is not completely correct, that number needs to round up :( I can submit another PR today when i get a chance or if you have time maybe you can. But I simply made is so it's no precision to print out the integer part of the float but that's not correct, the amount always rounds up to the next whole number no matter what from what my PM just told me. Do you want me to take this on or is that something you want to do quickly?
Is the behavior to round up unique to this field? Adding a roundUpFloat type sounds like the solution to me.
Just thinking this one through, I've been trying to find the CTR/SAR guide where it gives guidance on round up/round down or just truncate and I can't find definitive verbiage on that. So this could also just be dealt with client side thought by prerounding before using this field. I might be able to work around this without a change to the library. And for the record when it was using scientific notation here, it did print out rounding it up to the next dollar. Let me know if you think i should submit any code for this.
If this field always needs to be rounded up we can implement that in the library. Renaming the type added in this PR to add round-up behavior works for me.
Two issues that this PR deals with
After this change it becomes: <fc2:EFilingBatchXML TotalAmount="1252363" PartyCount="1" ActivityCount="1"
Our workaround looked like this:
if totalAmount == 0 { fincenReport.Attrs = append( fincenReport.Attrs, xml.Attr{ Name: xml.Name{Local: "TotalAmount"}, Value: "0", }) }