epicor 9.05.701

We need a new date field that is similar to Ship By Date (OrderRel.ReqDate) so that the OrderRel.ReqDate can be changed but we still have visibility of what date was originally entered by looking at the new field.

The new field should:

  1. automatically generate when Ship Date first entered.
  2. not be changeable without a reason code (customer request, import license issues etc).

i can create a date field easily enough, but how do i make it look at the shipby date?..is it using an EpiRetrieverCombo from the toolbox?..if so, won’t this just pull the data and update everytime the shipby date field updates?..ideally it needs to generate it when shipby is first entered only.

I would think you could populate the date field by ABL code or a BPM. I have seen something similar at another place I worked. I will see what I can find.

your right, i think a BPM will do that bit…however, i don’t want it to update everytime.

I think we had code on the customization that set the field and then marked it read only. I will see if I can find it.

1 Like

Since this is on the OrderRel table, you’re a little more constrained by what BPMs can do as the FIRST release on any line is created with incantations and possibly goat sacrifices (that is to say, NOT by a business object). You’d need a Data Directive, and you’d have to try some different conditions (I don’t know if RowMod is available on OrderRel or not, or you could also try a test on the date value).

Hi Mark,

We have a similar need but have handled it a bit differently. Years later, we still go back on forth on which would be best, our way or your planned way.

We also need to store original planned ship by date and also need to have a date that we use for schedule creep. You look to be planning to use UD field to hold date stamp original planned ship date and use ReqDate for schedule creep date. We do not do it this way. I do like your way in that required dates for materials will be aligned with when you currently think you’ll be able to ship. I do not like your way in that there is no way to tell in regards to material requirements dates what jobs have already been pushed back to what degree by just using timephase.

Any others out there who want to chime in on how they deal with their sales order release dates/schedule creep???

Here’s some code from a OrderRel In-Transaction data directive bpm that does the initial “get my ReqDate and put it into my latest scheduled shipping date (Date01)”. Date04 does not store anything for us and we use it for date comparison for null. It’s probably not the most efficient means of doing this, but it’s robust for years. You could toss your conditions in for blank date and reason code <> “” early on.

/* Replace the Latest Scheduled Ship Date (OrderRel.Date01) with OrderRel.ReqDate if Date01 is null*/

foreach (var ttOrderRel_xRow in ttOrderRel)
var ttOrderRelRow = ttOrderRel_xRow;
if ((DateTime?)ttOrderRelRow["Date01"] == (DateTime?)ttOrderRelRow["Date04"])
ttOrderRelRow["Date01"] = ttOrderRelRow.ReqDate;


1 Like

Could you explain the “rowmod” condition that you mention?
Is this something that can basically say only look at the first time it was modified?

Thank you

The RowMod field in a tt table is the record’s status. A means an added row (new record), D means deleted row, C means changed row (added or modified).

I just checked, and on the Data Directives for OrderRel that field isn’t there… so you’d want to use the condition “there is at least one ADDED row in the specified table”. That will ensure you don’t update the field each time the record is modified.

1 Like

Could you not just take the first row from bookrel that contains a date?

The table tracks all changes to the release for qty and date, including the date and time with user who updated.



1 Like

wow, thank you,
This is the first time i’ve come across this particular table “bookrel”.
This could be most useful.
Thank you.

There are some caveats to know about the Booking tables:

  • Records are written whenever the “Ready To Process” flag is set.
  • The system tries to be smart about partially shipped items by updating records if you change qty or price for line items shipped.
  • However, it does this for the whole order and all lines completely shipped get debooked. :slightly_frowning_face:
  • One would think the sum of the booking records would equal the current order total which for the reasons above, this is not the case.
  • In earlier versions of Vantage/Epicor, Sales Kits were not handled correctly.

Mark W.

1 Like