@pros68 Welcome aboard
You seem to be asking us to design this application for you and unless you find an expert you can hire, that is probably not going to happen without you at least making a start. Many people will build samples and write code for free but you do get what you paid for. It leaves a lot of work for you to do.
Do you have any experience creating Access applications? Do you have any programming experience at all? Do you have any experience creating Schemas (all the tables you need to define to hold the data you are going to capture and work with). Can you create queries?
Converting a spreadsheet to an Access application is certainly doable but you can't just push a button and expect it to happen. There is no conversion tool available for the program logic. Eventually, you will be able to import the data from the spreadsheet but that is all you can automate of the process. Generally, spreadsheets are short and wide but tables are long and narrow. So, as you are trying to convert your spreadsheet to tables to hold the data (the processing logic comes later), think about the wide/narrow concept. In a spreadsheet the presentation layer and data layer are conflated so you end up storing data the way you want to see it rather than the most efficient way for storing it and processing it. For example, you would be inclined to create a worksheet with 12 columns to represent months of a year. And then additional sets of 12 columns if you want to store multiple years. But, in a relational database, each row in a table would represent only one month. So instead of having one row with twelve months * the number of years, you will end up with one column (for the month plus other columns for the related account number and date) with twelve rows * the number of years so that each month of each year is a separate record. So what happens in excel is you start with 12 calculations. One for each month then multiply times as many years as you want then times one for each row which ends up being thousands. If you continue that design pattern into your relational database, you end up with 12 calculations which will be a dramatic reduction (assuming you bit the bullet and conceded to use a separate row for each year). However, if you properly normalize the data, you end up with ONE calculation. It ultimately reduces your workload and potential for error enormously. Granted, you use copy and paste a lot to duplicate the data in a spreadsheet to make all the rows and columns you need with individual calculations for each. Think of the potential for error in that sea of thousands of calculations and tell me you've never run into a spreadsheet that had no bad formulas.
You need to start by analyzing the data. Define what items are Entities and then what cells represent attributes of that entity. I don't speak Italian so I can't even begin to do this type of analysis for you. Perhaps you'll luck out and find someone who can give you a start on this.
Entities are main things like Customers, Orders, Employees, Accounts. Each of these has some number of data items that define them.
Make a stab at the tables and people will jump in to help. Even if you don't convert the spreadsheet to English, if you provide a summary in English of what the spreadsheet does and what you want out of the Access application, that will be very helpfu.
database2.PNG
total.PNG
