Now Available in Community - New TechTalk Videos for 2020
Read More about New TechTalks for 2020
2020 release wave 1Discover the latest updates and new features to Dynamics 365 planned through September 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
We are experiencing incorrect behavior in Incremental push export for three data entities:
All of those three are standard entities enriched with additional attributes for business reasons, so there’s some degree of customization. These three data entities will be used to move data from Dynamics to an external system using a recurring data project for each one of them.
I’ll try to describe our test scenario by using real test cases for General journal data entity but keep in mind this is happening also for the other two data entities.
Data entity: General journal
Execution frequency: 10 mins
Default refresh type: Incremental push
Change tracking: Primary table
Filters: Specific Journal name (“PF”) + Posted = Yes
See picture to relate to the following cases:
General journals TOEV-000308, TOEV-000309, TOEV-000310 are posted between 03.37 PM and 03.39 PM within the execution interval 03.35 – 03.45:
See pictures below for the exported excel spreadsheet:
Case 1: OK
General journal TOEV-00311 is posted on 03.48 PM, between the execution interval 03.45 – 03.55:
I don’t get why the first row had to be exported. It was there (correctly) in the former execution and no other changes had been made on the primary table, regarding the journal TOEV-000310.
Case 2: KO
Have anyone of you experienced the same issue? It seems to me that that something I don't know about is triggering somehow a change in the primary table so that rows already posted are being taken in account again to be exported. I also opened a support ticket to MS.
Thanks for your feedback.
How these journals are posted? If manually, could it be that user open the journal (it's marked as blocked) and posted it -> Export happened -> User close the journal and journal lock is removed -> triggers change in CT -> exports data in next export run?
Rows exported in case 1 and rows exported in case 2 appear to be duplicated.
It seems that this issue only knows MS support.
Thanks. I'm waiting for them to send me some update.
Hello Sergei. That's an interesting idea, I didn't consider it. I'l try to look into it.
Business Applications communities