Not a developer, so apologies if this is beginner stuff.
I have a stock movement export, about 4000 rows a month, out of a system that writes dates three different ways depending on which depot keyed them in. I want a monthly summary by product line with returns split out.
When I ask for that I get something that looks right and is not. Last time it quietly dropped every row where the date would not parse, about 300 of them, and handed me a clean looking total that was 7 percent light. It did not mention doing it.
What do people put in the request to stop that happening? I have a feeling I am asking the wrong way rather than asking for the wrong thing.
You are asking for the right thing. The fix is boring: make it show the working before it gives you an answer.
On any messy data job I ask for this order. Load the file and tell me the row count. Tell me how many rows fail to parse in each column, and show me five examples of each kind of failure. Then stop.
Only once I have looked at that do I ask for the summary. Most of the time the interesting thing is sitting in the failures, and in your case the whole answer was in step one.
Also ask for the row count again at the end and compare. Anything that silently drops rows gets caught by arithmetic.
Same problem in a completely different job. The rule I ended up with is that it is not allowed to skip anything without telling me.
I phrase it as: never discard a row, put anything you cannot handle into an exceptions list with the reason why. The exceptions list is now the first thing I read, before the answer.
One more. Ask for the code, not the answer.
If it writes you a small script that produces the summary, you can run it again next month, and the parsing decisions become visible instead of happening somewhere you cannot see. You do not have to be able to write the script to read it and ask why line 12 is throwing rows away.