We have a customer that will either reuse a previous purchase order or share a purchase order between 2 ship-to locations. When this occurs, we need to update the existing Purchase order to something else, since we have the check box check for duplicate orders turned on. If turn off that check box, we can manual enter, and order and it will go in. If we DMT an order in it will create the order, but if we EDI an Order in the system will update the existing order and not create a new order. This appears to bypass the business logic.
One thought is to append the shipto to the purchase order (something like 123456789@1234
then when we send out documents to strip the store number. While this might work, I am concerned with this solution. Really, I would like to have EDI work the same was as a manual order or DMT.
If we did this, we could look at using a baq to report on a reused PO Number and display from a BPM form similar to what Jose did in this video → Advanced BAQs and BPM Forms - YouTube
Have any of you run into this issue and if so, how do you work around this. Again, the issue is with EDI orders not a manual entered order or DMT. If we turn off the check box, then we have to look at some other controls - I do understand that.
Lastly, we are a SaaS client and have to use the tools within here.
Other applications can identify duplicate records with a combination of ID and dates, rather than ID alone.
It is possible, though, to copy the original PO value as a UD field – used for EDI ASNs and invoices – and then append the PO date to the Epicor PO ID as part of your EDI processing.
PO 12345 would be identified as 12345-221118.
This would process EDI PO change transactions as well as distinctly new POs.
@GTI07094 EDI is not going to not combine them. I tried to make the app file have a header line per line, but as long as the PO was the same it make one order. Are you getting an 860 or are hey sending another 850 with an old number? If it is an 860 you could set them to always review.
There are DemandImportEntry BOs you can use with a bpm to update the EDI PO number, so it would make a new order. Even a period added at the end would make it different. You could then have another bpm that removed any periods at the of PO numbers.
At a previous employer, the Oracle Financial (OFS) application would allow inbound transactions to be considered as duplicate with a combination of transaction ID, customer ID and/or transaction date.
(I do not know if Epicor allows this flexibility, though.)
Because the Demand screens allow EDI value to be updated, though, for audit purposes we maintain certain original key EDI values in a combination of Datenn, Numbernn and ShortCharnn fields.
Our EDI application is indeed able to combine fields as needed, though, as well as transfer values to UD fields.
@PGirard I did not think Epicor truly had 855 capabilities. I am in the process of updating order entry to support reason codes. How have you supported this for EDI/EMail/ETc
Original EDI PO values - required to generate an 855 transaction - should be available in various UD fields indicating shipment date, quantities, unit prices, etc.
If EDI transaction processing is not available, these UD fields can be generated with Epicor (Demand. . .Contract) Data Directives, before user have access for manual update. The UD fields will be copied forward to Demand Entry and Sales Order Entry records.
The Sales Order records generated with Sales Order Acknowledgment report would contain all required original and current fields required for an 855 transaction.
Automating Sales Order Acknowledgements could be available as soon as the Sales Order is created from Demand Entry, but only as long as EDI Order updates are restricted to Demand Entry screen changes.
If order updates are also routinely changed in the Sales Order Entry screens, 855 transactions would likely be deferred as manually-generated Acknowledgment requests in order to ensure that the trading partner receive your current information.