When we create a new PO, add a part on the lines tab and set a due date, the releases tab shows the due date and has a blank promise date. However, if we go to the releases tab and change anything (i.e. the qty), hit save, then the promise date automatically gets filled by the existing due date.
We want to keep the promise date blank because we are waiting for confirmation from the vendor before we fill in that date.
I don’t see any pre/post processing on PO.Update, nor do I notice any code on the form itself causing this. Any idea why this is happening and/or a solution to prevent it? Why doesn’t the promise date get filled in when we set the due date on the lines tab?
What do you use the “Confirmed” flag for on PO Header? This flag can be used to indicate that the vendor has accepted the order and confirmed the dates. Create a dashboard showing POs that are Open, Approved, but not confirmed to give your buyers a list to chase up. Even better, make that dashboard updateable so they can easily flag it as confirmed.
Well, we don’t really use the confirmed flag on PO Header. The promise date functions as our confirmation because we are tracking at the release level, not at the overall PO level.
After years of working with ERP systems, I am at the point when I hear, “We’ll use this field for that”, that I just say, “Let’s use a UD field because the system is using that field for another reason and we can’t change that.” I have been burned so many time trying to fight the system. In the end, it’s really easy to add/use the UD field in Epicor. Just a grumpy old man’s humble opinion.
That’s understandable and the direction I’m leaning. What I’m confused by is why the promise date isn’t automatically populated when adding a line, BUT it is automatically populated when updating anything on the release tab. Why the difference? The difference right there is causing much confusion internally.
I agree with what Mark says about creating a new field, and I do that routinely for new things. Agree that re-using a system field is poor practise – I’d like to point out though that the confirmed flag in this instance is exactly how the field should probably be used!
