Cannot process earlier transaction? about rp2 HOT 5 CLOSED

Thank you! Sorry I haven't had time to upload my data yet. I will check what you found and confirmed it! Thanks again

from rp2.

Thanks for opening an issue! I need more information in order to understand what is happening:

• would you be able to attach an (anonymized) file that reproduces the problem?
• are these all the transactions you have or are there more? I need to know the full context to understand why the error message is being given.
• are you using FIFO or LIFO?
• what version of RP2 are you using?

from rp2.

I'm not able to reproduce the issue. I created an input ODS file with the transactions you indicated + its respective config file (both attached): I then used them with RP2, which computes and generates results correctly both with FIFO and LIFO.

Here are the command lines I used:

• rp2_us -m fifo -o output/ -p issue8_ issue8.config issue8.ods
• rp2_us -m lifo -o output/ -p issue8_ issue8.config issue8.ods

I think you may have extra transactions in your file: the error is probably telling you that you are selling lots that have not been bought yet, but I would have to see the file to be sure.

Also make sure you're using the latest version of RP2.

from rp2.

I was able to reproduce the error message by adding one single OUT transaction before the one you indicated (see picture below): the error message is correct and not an RP2 bug.

The error is rightly saying that some lot fractions are sold before they were acquired (which is not allowed). Here are the details of the computation, using the example from the picture and assuming FIFO accounting:

• 0.01 from OUT 2021-01-12 is mapped to IN 2021-01-03 (leaving 0.99 in that lot)
• 0.99 from OUT 2021-01-13 is mapped to the 0.99 leftover of IN 2021-01-03 (exhausting the lot)
• 0.01 leftover from OUT 2021-01-13 is mapped to the next IN lot, which is 2021-11-06

However the last step triggers the error, because the date of the IN lot is later than the date of the OUT lot, which denotes an impossibility.

This is not a bug: it's just pointing to an inconsistency in the input data (it has been entered incorrectly or perhaps some transactions are missing).

Attaching the modified ODS with the extra OUT transaction: issue8_repro.zip.

I think this may be what's happening with your data as well, however if you think your case is different than what was explained above, please attach (or send) a file that reproduces the problem and I'll take a look.

from rp2.

Closing the issue.

from rp2.