Is there a weekly report in the scrum guide?

You are correct in that the SG does not mention this, because the Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. 

The PB & SB should really be enough for interested parties to see how the product and current sprint are progressing. 

When you start creating report, you start using metrics.  Metrics can be useful if used for the purpose of allowing the developers to see how the sprint is progressing, however, they should not be used by management to determine how the Developers are performing. 

What would the weekly report contain?  After you answer that question you should look at the information that the team radiates and determine if that information is missing.  As a Scrum Master I do not like to add additional reporting or work.  Instead I try to teach those asking for information where they can find it and how to interpret the information that is being radiated already. 

But if you want to create a weekly report, as you said there is nothing in the Scrum Framework about doing so.  That is because reporting is usually seen as a procedural activity and frameworks do not dictate that level of information.  Process is entirely up to the team and organization but if you want to say that you are using Scrum, the processes should not hinder the ability to use the framework for success. 

Is it okay if I add a weekly report for the company and stakeholders? Because the Scrum guide is not mentioned.

What would they actually use this weekly report for, and why?

Hi all

Thank you for the response.

What would the weekly report contain? 

The weekly report contains the burn-up chart, issues during the sprint, the solution to the issue, and a summary of the progress of the project. 

What would they actually use this weekly report for, and why?

So, the weekly report is an activity that has been determined by the company so that the company management and stakeholders can find out the progress of project development.

I'm a little confused whether the weekly report is included in scrum or not? Because in the weekly report also includes the burn-up chart.

the weekly report is an activity that has been determined by the company so that the company management and stakeholders can find out the progress of project development.

Why won't the ongoing delivery of product value be enough? In Scrum each Sprint is a project, by means of which Done and immediately usable and valuable increments are provided. 

Scrum Artifacts enable transparency. We can create and use information radiators that pull information from the Scrum artifacts, such as a burndown chart, that help with transparency. I get the feeling management doesn't want to let go of their old waterfall habits of managing the team through status/metrics. Does management understand that quality is not negotiable in Scrum but Scope is? Meaning we forecast the work to be done in the sprint not commit to delivering it. If they plan on managing the team based on the report, then their missing the fact that the Scrum team is self-managing. If they are not planning on taking any action, then why isn't the Sprint Review enough?

I'm a little confused whether the weekly report is included in scrum or not? Because in the weekly report also includes the burn-up chart.

Going to start with this and point out that there is absolutely no where in the Scrum Guide that references a Burn-up chart.  In fact no charts are referenced anywhere in the Scrum Guide.  There is also nothing in the Scrum Guide about reports.  The two are process based and the Scrum framework leaves process up to the people doing the work. 

In your case your organization has defined a report and it's content.  That is your organization's process decision. I am pretty sure that there are many frequent contributors to this forum, myself included, that might argue the merits of it but there is nothing we can say about it being right or wrong.  As @Eric Bobo points out, many have adopted other techniques to radiate the information but there is nothing to say that those are better for all organizations. @Ian Mitchell is also pointing out that there are some Scrum events that can be used for this purpose. He also alludes to the Scrum theory of using empiricism to guide decisions via Transparency, Inspection, and Adaption. 

In the end, your organization is free to make any procedural decisions it chooses. But as a Scrum Master you need to help the organization to understand how their interactions inhibit or support the Scrum Team from achieving its goals.  You should facilitate the learning of how or if this report impacts the Scrum Team and then communicate that to all stakeholders. Help the organization determine if there is a better way to radiate this information so that it isn't a single point in time communication and can be a continuous communication method. Management can be a stakeholder in a Scrum Team's work so communication to them in a manner that they can/will consume is important.