web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

Sign Up for Ask a Community Pro Today!
Introducing our New Video Series: Community Spotlight
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Small and medium business | Business Central, N... / Edit in Excel won't pr...
Small and medium business | Business Central, N...
Suggested Answer

Edit in Excel won't properly connect

(3) ShareShare
ReportReport
Posted on by JL-23101125-0 26
Recently a user complained that on the production platform of BC SaaS he used the "Edit in Excel" share option for the Items List, but the generated Excel file wouldn't properly connect and download the list, raising error 
Error Loading Metadata

Details:
Please check server connection, verify the current user has proper access, and try again. Error message: 'Metadata was unable to be retrieved for entity Item_Card_Excel as it was not found.'
 
I tried in my dev sandbox ad got the same issue.
 
Copilot advised to change language to English and retry. I was already using "English (UK)" but changed to "English (US)", just in case. Also the regional setting was changed accordingly. Repeated my tests. Same error.
 
Checked the Web Services, located the "Item_Card_Excel" web service (page 30) and it was there. Deleted the web service, repeated the "Edit in Excel" from the Items List. The web service was automatically recreated and published, but the newly generated "Item Card (2).xlsx" also didn't connect, raising the same error.
 
Tried the "Item_Card_Excel" Web Service hyperlink in Postman. Got error 404.
 
tried the "Vendor_Card_Excel" Web Service hyperlink in Postman. Got a complete valid XML response.
 
 
On another hand, "Open in Excel" for Items List works perfectly. Also, "Edit in Excel" for the Vendors List works perfectly. This one also uses its published web service on BC.
 
Checked the metadata document that one can download on the Web Services page. Found:
 
<NavigationProperty Name="Vendor_Card_Excel" Type="Collection(NAV.Vendor_Card_Excel)" ContainsTarget="true"/>
 
But nothing there, about "Item_Card_Excel". It looks now pretty obvious why the thing doesn't work. When the "Item_Card_Excel" web service is created, it isn't providing any metadata, getting confused.
 
 
Any ideas, please?
Categories:
Dynamics 365 Business Central
I have the same question (0)
  • JL-23101125-0 Profile Picture
    JL-23101125-0 26 on at
    Update:
     
    Tried the "Edit in Excel" on a plain sandbox without any custom extensions. It worked.
     
    Got back to my sandbox where it didn't work previously, and started removing my extensions. Identified one culprit after removing it. "Edit in Excel" now works.
     
    Will need to investigate my AL code in that extension, created about 2 years ago, to try to determine what's on it that might be interfering.
     
    Will post here any positive findings.
  • Suggested answer
    JL-23101125-0 Profile Picture
    JL-23101125-0 26 on at
    Update 2:
     
    After investigating my BC extension, found that if I'd publish a page extension to the Item Card, the "Edit in Excel" would fail. That page has 11 additional fields in a group, provided by the table extension. 
     
    After a considerable number of trial/error, by first supressing the group, then the fields, then publishing one by one, Murphy's law applied as always (joke). The last field on the page was the culprit:
     
                    field("Country-Region of Origin Code"; Rec."Country/Region of Origin Code")
                    {
                        ToolTip = 'Specifies a code for the country or region where the Item was manufactured.';
                        ApplicationArea = All;
                        Description = 'A****.6';
                    }
     
    The size of the field name was 29; the "-" and the "/" were under sight, but because the "Edit in Excel" worked while having this field on the table extension, my attention went to the name of the field on the page, not the Rec. fieldname.
     
    Started to test with "Country Region of Origin Code". Still 29 chars. Didn't work.
     
    Tested with "CountryRegion of Origin Code". 28 chars. That works.
     
    Tested with "Country-Region ofOrigin Code". 28 chars. That also works - the "-" is not causing the problem. The size of the fieldname is.
     
    Ended-up adopting the fieldname "Country/Region of Origin". Even less characters and adopts the "/". And it works with "Edit in Excel".
     
    Happy days.
     
    Conclusion: Having more than 28 chars on a fieldname on a page extension to the Item table (will tend to believe this would also affect, e.g. the Vendor Card, was causing issues on the "Edit in Excel" functionality on the Excel side,, that wasn't able to retrieve the required dynamic metadata. 
     
     
  • Suggested answer
    OussamaSabbouh Profile Picture
    OussamaSabbouh 9,231 on at
    Hello,
     
    This error means Item_Card_Excel is published but not registered as an OData entity, so it never appears in $metadata, which is why Excel fails and Postman returns 404; this is why Vendors work but Items don’t. The most common causes are an OData name collision, an extension impacting page 30 (Item Card), or a Microsoft regression. Quick confirmations are: publish the Item page under a different service name (or publish Item List – page 31) and see if it appears in $metadata, and test in a clean sandbox without non-Microsoft extensions. If it still fails there, it’s almost certainly a platform issue and should be logged with Microsoft support. Until fixed, the practical workaround is Open in Excel or using a custom/published Item List OData page for Excel edits.
     
    Regards,
    Oussama Sabbouh
  • Suggested answer
    JL-23101125-0 Profile Picture
    JL-23101125-0 26 on at
    Hey Oussama, you are right, the metadata wouldn't include a reference to "Item_Card_Excel" because it didn't dynamically successfully updated that, after (re)creating the web service with the same name. My issue - and took about a day to find out - was related to the size of the fieldname being bigger than 28 chars, not on the table extension, but on the page that was showing it. 
     
    Copilot, Grok, ChatGPT had provided answers that made sense, and in fact helped me narrowing the reasons of the issue, but none mentioned the length of page/page extension fieldnames greater than 28 chars potentially creating issues.
     
    Hope this helps someone else here.
     
    Regards, Joao
     
     

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

News and Announcements

Sign Up for Ask a Community Pro Today!
Introducing our New Video Series: Community Spotlight

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Congratulations to our 2025 Community Spotlights

Thanks to all of our 2025 Community Spotlight stars!

Congratulations to the December Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > Small and medium business | Business Central, NAV, RMS

#1
OussamaSabbouh Profile Picture

OussamaSabbouh 2,167

#2
Dhiren Nagar Profile Picture

Dhiren Nagar 1,184

#3
YUN ZHU Profile Picture

YUN ZHU 1,161 Super User 2025 Season 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans