October 26, 2026
Data engineering platform for adjusting SPED Fiscal and SPED Contribuições files
Mauro Sartori Koermandy; Vinicius Santos Andrade
DOI: 10.22167/2675-6528-202601246
Article prepared by the ResumeAI tool, an artificial intelligence solution developed by the Pecege Institute focused on synthesis and writing.
Summary
The monthly obligation to deliver the SPED Fiscal and EFD Contribuições files, essential for the calculation of taxes such as ICMS, IPI, PIS, and COFINS, frequently faces challenges due to errors identified by the Validator and Signer Program (PVA), which prevent transmission and require manual, repetitive, and error-prone corrections. The study aimed to develop a data engineering platform to automate fiscal adjustments and support the treatment of errors and warnings in these files. The methodology adopted framed the problem from a Data Engineering perspective, structuring a processing flow that involved importing fiscal files and validation logs, identifying inconsistencies, applying adjustment rules, and generating new versions for revalidation. The solution was developed based on Clean Architecture, organizing an automated flow of import, diagnosis, adjustment, auditing, and export. The results demonstrated the technical viability of the platform, which allowed for greater process control, traceability of changes, and organization of generated versions, consolidating functionalities that traditionally required fragmented manual interventions. It was concluded that the proposal proved effective in making SPED file correction safer, more traceable, standardized, and efficient, contributing to tax compliance.
Keywords: Process automation; Tax compliance; Digital bookkeeping; Information quality; Traceability.
1. Introduction
The Public Digital Bookkeeping System (SPED), established by Decree No. 6,022/2007 (BRASIL, 2007a), represents a milestone in modernizing the relationship between tax authorities and taxpayers. Its purpose is to standardize and share accounting and fiscal information in digital format. Among the essential SPED modules, the EFD Contribuições stands out, which covers the bookkeeping of PIS/Pasep, COFINS, and CPRB, being mandatory since 2012 (BRASIL, 2012a). Another relevant module is the EFD ICMS/IPI, also known as SPED Fiscal, dedicated to the bookkeeping of fiscal documents and state-level tax assessments (CONFAZ, 2009). The validation of these files is carried out by the Validator and Signer Program (PVA), official software from the Federal Revenue Service that applies consistency rules and prevents the transmission of files containing errors.
The motivation for this research arose from the practical observation of tax consulting activities over eight years, in which the adjustment of tax files proved to be a recurring, technically complex, and operationally burdensome task. In one of the analyzed scenarios, it was necessary to perform the retroactive adjustment of twenty-four EFD Contribuições files, which totaled approximately one hundred million lines. In another context, the processing of tax files became a continuous monthly activity for seven years, involving files with over ten million lines.
In both cases, significant difficulties were identified, such as dependence on specialists with concentrated knowledge, fragmentation of manual processes among text editors, spreadsheets, and the PVA itself, and low reuse of adopted solutions. Errors pointed out by the PVA prevented file transmission, making manual correction a repetitive, error-prone, and inefficient process. This reality highlighted the need for a more structured approach to ensure tax compliance and optimize work.
Given this panorama, it became imperative to propose a solution capable of structuring and supporting the fiscal adjustment process in a safer, standardized, and traceable manner. The problem was framed from the perspective of Data Engineering, and the solution architecture was based on Clean Architecture, aiming for greater process control, traceability of changes, and organization of generated versions. This theoretical and practical approach seeks to mitigate the deficiencies of traditional correction methods.
Thus, this work is justified by the need to make SPED file correction safer, traceable, standardized, and efficient, and aims to develop and evaluate a data engineering platform to support the reading, diagnosis, adjustment, and revalidation of SPED files, through a relational database, batch or specific adjustment application, auditable record of changes, and generation of a new file version for revalidation.
2. Material and Methods
The research was characterized as applied and exploratory, oriented towards the development of a solution for the treatment of inconsistencies in digital fiscal files. The methodological approach combined qualitative elements, used in problem analysis, requirements gathering, and definition of adjustment rules, with quantitative elements, used in observing the solution’s operation throughout the processing, correction, and generation of new versions for revalidation. The platform development followed an iterative and incremental logic.
The empirical object of the study consisted of files from the Public Digital Bookkeeping System (SPED), specifically the EFD Contribuições and EFD ICMS/IPI (SPED Fiscal) modules. These files, in plain text format, are delimited by the “pipe” character (|) and organized into hierarchical blocks of records. For the implementation and validation of the platform, anonymized real files and synthetic files were used, allowing for controlled tests and the reconstruction of the hierarchy between records.
The solution architecture was structured based on Clean Architecture (Martin, 2019), organized in layers with well-defined responsibilities. This organization aimed to separate business rules from interface, persistence, and infrastructure elements, favoring clarity in the processing flow and system maintenance. The architecture was distributed into four main layers: domain, application, infrastructure, and presentation, as illustrated in
.
The platform’s development environment employed PostgreSQL as the database management system (POSTGRESQL GLOBAL DEVELOPMENT GROUP, 2024) and Python as the main implementation language (PYTHON SOFTWARE FOUNDATION, 2024). The graphical interface was built with PyQt6. The database was run in a Docker container using Docker Compose, and the desktop application was executed locally.
For development and validation support, Visual Studio Code, DBeaver, and pgAdmin were used. The testing phase included pytest and simulated objects (“mocks”). Additionally, artificial intelligence support was employed through GitHub Copilot, with review and validation of outputs by the author, to optimize the coding process.
The data organization in PostgreSQL was structured based on distinct schemas to separate responsibilities and ensure control over information. A shared reference “schema” was adopted for metadata, an application “schema” for control and configuration, and specific client schemas for isolated storage of files, rules, and logs. This strategy is detailed in
.
The domain entities were defined to represent the central elements of the import, validation, adjustment, and export cycle of fiscal files, concentrating the essential information of the problem. Among the modeled elements, the SPED records, the errors identified by the Validator and Signer Program (PVA), the adjustment rules, the validation cycles, and the audit artifacts stood out, as presented in
.
The use cases were defined to represent the main operations performed by the platform in processing fiscal files. They orchestrated actions such as reading files, identifying inconsistencies, applying adjustments, recording changes, and generating new versions for revalidation, maintaining consistency with Clean Architecture. The general use case diagram is presented in
.
The platform’s processing flow was structured in sequential and traceable steps: loading, treatment, and extraction. In the loading stage, the SPED file was read in plain text format and the validation log generated by the PVA, importing this information into the relational environment. The records were identified, classified according to the layout, and associated with their sequential position, preserving the hierarchy, as illustrated in
and
.
The association algorithm between the PVA log and the imported records was developed to relate the error and warning reports generated in the official validation with their respective stored records. The system interpreted the PVA messages, identifying the record code, the type of inconsistency, and the problem description, linking each inconsistency to the specific record or a set of related records, as demonstrated in
.
In the processing stage, the flow concentrated the operations of record association and inconsistencies, application of adjustment rules, audit of changes, and control of validation cycles. The adjustment rule application algorithm executed corrections on specific fields, allowing batch or point adjustments, always with a record of the previous and subsequent state of the modified information, as detailed in
.
The extraction stage consolidated the adjusted data and generated a new version of the file in compliance with the required layout, allowing its submission to a new validation cycle in the PVA. The system reorganized the records, recomposed the blocks, and recalculated the totaling records. The export and generation algorithm for the new version of the SPED file is illustrated in
.
The audit and traceability of changes were structured to record the modifications made throughout the adjustment cycles. Whenever a correction rule was applied, the system stored the affected record, the changed field, the previous and subsequent values, the rule used, the time of the operation, and the link to the corresponding cycle. This logic is presented in
.
After exporting the new version of the SPED file, the platform supported the revalidation step in the PVA, checking if the inconsistencies had been eliminated or reduced. The adjusted file was submitted to the official verification process, generating a new log of errors, warnings, and notices, which made it possible to compare the situation before and after the treatment, as illustrated in
.
The platform’s graphical interface was developed to concentrate, in a single environment, the main operations necessary for processing SPED Fiscal and EFD Contribuições files. It allowed the user to access functionalities for importing, reading the PVA log, applying adjustment rules, auditing changes, exporting new versions, and consulting conference reports, as evidenced in
.
The platform’s testing strategy verified the functioning of the main stages of SPED file processing, covering from data import to the generation of the new file version for revalidation in the PVA. Tests were executed on central functionalities in representative usage scenarios with SPED Contribuições and SPED Fiscal files, according to the strategy presented in
.
Aspects of LGPD and security were considered, including access control, organization of user profiles, logical segregation of processed data, and recording of operations performed. These mechanisms aimed to reduce operational risks and reinforce the security of the fiscal file processing environment, as illustrated in
.
3. Results and Discussion
The results obtained with the platform’s development evidenced the technical viability of the proposed solution to support the automated processing of inconsistencies in SPED Fiscal and EFD Contribuições files. The implementation allowed for the structuring of an integrated workflow for importing, associating records and notes from the Validator and Signer Program (PVA), applying adjustment rules, auditing changes, exporting new versions, and revalidating processed files. This chain demonstrated that the practical problem identified in the work could be addressed through an organized, traceable solution aligned with the analyzed fiscal context, overcoming the limitations of fragmented manual processes.
From an operational point of view, the platform concentrated in a single environment functionalities that, in traditional situations, used to require manual queries, direct inspection of the text file, repetition of adjustments, and new verification in the PVA. With this, a gain was observed in the organization of the process, greater control over validation cycles, and better visibility of the changes made to the records. The association between the PVA log and the imported data proved particularly relevant, as it allowed transforming error and warning messages into structured information for diagnosis and correction, significantly optimizing the time and accuracy of the necessary interventions.
System architecture
The developed solution was structured based on Clean Architecture, organized in layers with well-defined responsibilities, in order to separate business rules from interface, persistence, and infrastructure elements. This organization favored the clarity of the processing flow, system maintenance, and gradual evolution of the platform, allowing internal solution components to remain less dependent on external implementation details. The architecture was distributed into four main layers: domain, application, infrastructure, and presentation, according to Martin’s (2019) principles, which ensured a solid foundation for the system’s scalability and adaptability.
In the context of this work, the architecture was distributed into four main layers. The domain layer was responsible for the central entities and rules of the problem, while the application layer orchestrated the use cases. The infrastructure was intended for database access, file reading, and auxiliary services, and the presentation was responsible for the graphical interface used by the user. This structure contributed to organizing the import, diagnosis, adjustment, audit, and export cycle of fiscal files, maintaining greater separation of responsibilities and adherence to the objective proposed in the work.
PostgreSQL Schema Strategy
Data organization in PostgreSQL was structured based on distinct schemas, with the objective of separating responsibilities and ensuring greater control over the information handled by the platform. A division was adopted between a shared reference schema, intended for system metadata and common structures, an application schema, focused on control and configuration elements, and specific schemas per client, intended for isolated storage of files, rules, logs, and processing results. This strategy favored the organization of the environment, reduced the risk of mixing data from different contexts, and contributed to the traceability of operations performed throughout the validation cycles.
In the context of the proposed solution, the use of specific per-client schemas also allowed preserving the data isolation logic and facilitating the replication of the necessary structure for new work environments. Furthermore, this approach supported the separation between original data, adjusted data, and auxiliary processing elements, maintaining consistency with the proposal for auditing, versioning, and controlling changes applied to fiscal files. The strategy adopted in the database became an important component for the technical organization of the platform and for supporting the diagnostic, adjustment, and revalidation flow developed in this work.
Domain Entities
The domain entities were defined to represent the main elements involved in the cycle of importing, validating, adjusting, and exporting fiscal files. These entities concentrated the essential information of the problem, regardless of interface, database, or infrastructure details, maintaining adherence to the Clean Architecture proposal. Among the main elements modeled, the SPED records, the errors identified by the PVA, the adjustment rules, the validation cycles, and the audit artifacts stood out, all organized in a way to preserve the traceability of the changes made throughout the processing.
In the context of the proposed solution, this modeling allowed the system’s core to be structured around the most relevant concepts of the treated fiscal domain, favoring the separation between business rules and technical implementation details. Thus, the domain entities served as the basis for the application’s use cases, supporting operations such as reading files, associating records and inconsistencies, applying adjustments, and generating new versions for revalidation. This approach is crucial for maintaining the integrity and consistency of fiscal data throughout the entire processing.
Use cases
The use cases were defined to represent the main operations performed by the platform throughout the fiscal file processing cycle. Based on the domain entities modeling and the adopted architectural organization, these use cases began to concentrate the orchestration of actions necessary for reading files, identifying inconsistencies, applying adjustments, recording changes, and generating new versions for revalidation. This organization allowed separating business logic from the interface and infrastructure layers, maintaining coherence with the Clean Architecture proposal, which facilitates system understanding and evolution.
In the context of the developed solution, the use cases structured the application’s functional flow around central operations, such as importing the SPED file, loading the PVA log, associating records with validation notes, applying adjustment rules, auditing the previous and subsequent states, exporting the new version of the file, and controlling validation cycles. Thus, the use cases served as a link between the domain core and the solution’s external components, supporting the coordinated execution of the steps that make up the proposed diagnosis, adjustment, and revalidation process in this work.
Processing flow: loading, treatment, and extraction
The platform’s processing flow was structured to organize, sequentially and traceably, the stages of loading, processing, and extracting fiscal files. In the loading stage, the system read the SPED file in plain text format and the validation log generated by the PVA, promoting the import of this information into the relational environment. At this moment, the records were identified, classified according to the corresponding layout, and associated with their sequential position in the file, preserving the hierarchy necessary for the subsequent analysis and adjustment stages.
In the processing stage, the flow concentrated the operations of record association and inconsistencies, application of adjustment rules, audit of changes, and control of validation cycles. This phase allowed for action on both batch adjustments and specific interventions, always with a record of the previous and subsequent state of the modified information. Finally, in the extraction stage, the platform consolidated the adjusted data and generated a new version of the file in compliance with the required layout, allowing its submission to a new validation cycle in the PVA, ensuring data conformity and integrity.
Record import and classification algorithm
The import and classification algorithm for SPED records showed the sequential reading of the text file, the identification of record codes, and the initial organization of information in the database. This stage allowed the imported data to be structured in a traceable manner and in accordance with the fiscal layout, serving as a basis for the subsequent stages of association with the PVA log, application of adjustment rules, and re-exportation of the file. Sequential reading and precise identification of records are fundamental to ensuring that the original file structure is maintained and correctly interpreted by the system.
Complementarily, the preservation of the original file hierarchy required linking parent and child records through sequential identifiers. This hierarchical representation was implemented using the NUM_SEQ and NUM_SEQ_PAI fields, employed to reconstruct the logical chaining between imported records in the database. This approach ensures that the structural integrity of SPED files is maintained, allowing adjustment and revalidation operations to be performed consistently and without loss of context.
Association algorithm between PVA log and imported records
The association algorithm between the PVA log and the imported records was developed to relate, in a structured way, the error and warning reports generated in the official validation with the respective records stored in the database. After importing the fiscal file and the validation log, the system began to interpret the messages issued by the PVA, identifying elements such as record code, inconsistency type, problem description, and, when available, positional or contextual references necessary to locate the corresponding excerpt in the imported file.
From this association, it became possible to link each inconsistency to the specific record or set of records related to the identified problem, allowing for greater precision in the analysis and definition of corrective actions. This mechanism reduced the need for manual error location, strengthened the traceability between the PVA’s indication, the imported data, and the subsequent alteration, in addition to constituting a fundamental intermediate step between the structural reading of the file and the execution of the adjustments proposed by the platform, ensuring a more efficient and less error-prone workflow.
Rule application algorithm for adjustment
The rule application algorithm for adjustments was developed to execute, in a controlled and traceable manner, the necessary corrections on the records previously imported and associated with the PVA log entries. From the identification of inconsistencies and the selection of the corresponding rule, the system began to act on specific fields of the fiscal file, allowing for batch adjustments or specific interventions according to the context of each occurrence. This process was structured to preserve adherence to the SPED layout, avoiding alterations outside the scope of the identified inconsistency and maintaining tax compliance.
In addition to the execution of the correction itself, the algorithm also recorded the previous state and the subsequent state of each adjustment made, as well as the rule applied, the moment of the operation, and the reference to the corresponding validation cycle. This mechanism strengthened the traceability of modifications and supported the audit of changes promoted by the platform. Thus, the application of adjustment rules constituted the central stage of the solution’s treatment, connecting the diagnosis of inconsistencies to the generation of a new version of the file for revalidation in the PVA, providing comprehensive control over the correction process.
Algorithm for exporting and generating the new version of the SPED file
The export stage completed the platform’s processing, transforming the adjusted data into a new SPED file structured for re-validation in the PVA. In this phase, the system reorganized the records according to the sequence required by the official layout, recomposed the blocks, recalculated the totaling records, and saved a new version of the file, preserving the traceability of the processing performed. Thus, the user received a corrected, consistent file ready for review and transmission, which represents a significant advance compared to manual correction methods.
In this stage, the platform consulted the database and retrieved the final version corresponding to the last completed adjustment cycle, using the already corrected and audited records. Subsequently, the system recomposed the file in the SPED textual format, generated a new version for revalidation in the PVA, and kept the history of previous versions stored, ensuring traceability, evolutionary control, and audit support. This functionality is essential to guarantee fiscal compliance and information security, allowing companies to maintain a detailed record of all changes made.
Audit algorithm and traceability of changes
The audit and traceability of changes were structured to record, in an organized manner, the modifications made throughout the adjustment cycles of SPED files. Whenever a correction rule was applied, the system stored the affected record, the changed field, the previous value, the subsequent value, the rule used, the time of the operation, and the link to the corresponding cycle. This mechanism allowed for the reconstruction of the change history, support for the verification of executed adjustments, comparison of versions generated during file processing, and production of audit reports, ensuring transparency and evolutionary control.
The audit logic and traceability of changes made on the platform evidenced the recording of the previous and subsequent state of the data, the identification of the applied rule, and the link with the corresponding adjustment cycle. For example, adjustments such as the correction of CFOP from 1.4 to ICRS in cycle V00, or the alteration of ALIQT_ICMS to 1eiça in cycle V02 were recorded. These details are crucial for internal validation and for the review of the results obtained at each stage of fiscal file processing, reinforcing the platform’s reliability.
Validation of the new file version and reprocessing of the cycle
After exporting the new version of the SPED file, the platform began to support the revalidation step in the Validator and Signer Program (PVA), allowing verification of whether previously identified inconsistencies had been eliminated or reduced. In this phase, the adjusted file was again submitted to the official verification process, generating a new log of errors, warnings, and notices, which made it possible to compare the situation before and after the treatment performed and, when inconsistencies still persisted, to iteratively restart a new cycle of validation, diagnosis, adjustment, audit, and export until a more consistent version for fiscal transmission was obtained.
The revalidation logic of the new file version in PVA and the reprocessing of the cycle when inconsistencies still persist evidenced the iterative nature of the proposed solution. For example, a reduction in errors from four to two, and in warnings from three to one, was observed between the previous log and the new log after an adjustment cycle. This continuous reprocessing capability is fundamental to ensuring that SPED files reach the required level of compliance, minimizing the need for repetitive manual interventions and optimizing the work time of tax analysts.
Conference reports and analysis support
The platform was also structured to provide conference reports and analysis support, aiming to facilitate the interpretation of data processed throughout the adjustment cycles. From the imported, associated, corrected, and audited information, the system began to organize synthetic and detailed views on the identified inconsistencies, the adjustments applied, the altered records, and the evolution of each validation cycle. These reports allowed the user to follow the treatment performed more clearly, reducing the dependence on direct database queries and manual checks in the text file.
In addition to supporting operational conference, the reports contributed to the traceability and technical control of processing, as they consolidated evidence on the behavior of the archive before and after the interventions performed. For example, the platform displayed the number of errors identified per cycle, showing a reduction from 70 errors in cycle V00 to 2 errors in cycle V03, and detailed the adjustments applied, such as the correction of CFOP and VAT. Thus, the solution began to offer not only correction mechanisms but also analytical monitoring tools, useful for auditing, internal validation, and review of the results obtained at each stage of fiscal file processing.
Platform graphical interface and user operation support
The platform’s graphical interface was developed to concentrate, in a single environment, the main operations necessary for processing SPED Fiscal and EFD Contribuições files, allowing the user to access file import functionalities, PVA log reading, adjustment rule application, alteration auditing, new version export, and consultation of conference reports. In addition to centralizing these operations, the interface was designed to support the monitoring of processing in its different stages, making clearer the visualization of identified inconsistencies, validation cycles, adjusted records, and results generated throughout the operation.
The structured visualization screen of the imported records evidenced the organization of the loaded data and the support for operational analysis of the information processed by the platform. This functionality allowed the user to inspect the SPED records in detail, with information on level, parent, and fields, facilitating the identification of problems and the application of corrections. The interface, therefore, was not limited to being an isolated set of routines, but resulted in a functional environment supporting the technical treatment of SPED files, promoting greater efficiency and security in fiscal operations.
LGPD and security
The proposed solution also considered aspects of access control, user profile organization, logical segregation of processed data, and logging of operations performed, with the objective of reducing operational risks and reinforcing the security of the fiscal file processing environment. Although the main focus of the work was the automation of diagnosis, adjustment, and revalidation of SPED files, the platform was structured to restrict operations according to access profiles, maintain client data isolation through specific schemas, and record actions performed by users.
The organization of the main LGPD and security mechanisms considered on the platform highlighted access control by profiles, logical separation of data by client, and logging of operations for auditing and traceability purposes. For example, administrator, analyst, and guest profiles were implemented, with limited permissions for each, and a log history recording the user, operation, and time. This approach demonstrated, at a level compatible with the academic scope of the work, that the automated processing of fiscal files can be supported by basic security and governance mechanisms, with greater control over the use of the application and traceability of the processing performed.
In summary, the results obtained confirm the viability of the data engineering platform for automating tax adjustments and supporting the treatment of errors and warnings in SPED files. The solution proved effective in centralizing functionalities, increasing control and traceability of changes, and organizing validation cycles, contributing to making the correction of SPED files safer, standardized, and efficient, and consequently, to companies’ tax compliance.
4. Conclusion
This study aimed to develop a data engineering platform to support the reading, diagnosis, adjustment, and revalidation of SPED Fiscal and EFD Contribuições files, seeking to make the correction of fiscal inconsistencies more secure, traceable, standardized, and efficient. The technical feasibility of the proposed solution was verified, which structured an integrated flow for importing fiscal files and validation logs, association between records and notes from the Validator and Signer Program (PVA), application of adjustment rules, audit of changes, and export of new versions for revalidation. The implementation demonstrated significant operational gains by centralizing functionalities that previously required fragmented manual interventions, promoting greater control over validation cycles and traceability of modifications. The architecture based on Clean Architecture and the schema strategy in PostgreSQL were fundamental for the organization, maintenance, and adaptability of the system, consolidating a relevant practical contribution to tax compliance.
Although the platform has proven effective, it is important to recognize that its development occurred in an academic context, focusing on a specific set of inconsistency scenarios and adjustment rules, with no objective of fully replacing PVA or contemplating the entire normative and operational complexity of the fiscal universe. Furthermore, security and governance mechanisms were implemented at a level compatible with the scope of the work. For future studies, it is suggested to migrate the application to a web environment, create APIs to expand integration with other systems, reinforce access control mechanisms, and evolve to a Software as a Service (SaaS) model, which would allow for greater scalability and adaptability to new types of adjustments and validation routines, expanding its application potential in corporate contexts.
Bibliographic References
BRASIL. 2007a. Decreto nº 6.022, de 22 de janeiro de 2007. Institui o Sistema Público de Escrituração Digital – SPED. Diário Oficial da União, Brasília, 22 jan. 2007. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2007-2010/2007/decreto/d6022.htm. Acesso em: jan. 2026.
BRASIL. 2012a. Instrução Normativa RFB nº 1.252, de 01 de março de 2012. Dispõe sobre a Escrituração Fiscal Digital da Contribuição para o PIS/Pasep, da COFINS e da Contribuição Previdenciária sobre a Receita. Diário Oficial da União, Brasília, 02 mar. 2012. Disponível em: https://normas.receita.fazenda.gov.br/sijut2consulta/link.action?idAto=37466. Acesso em: jan. 2026.
CONFAZ. 2009. Ajuste SINIEF nº 02, de 3 de abril de 2009. Dispõe sobre a Escrituração Fiscal Digital EFD. Publicado no DOU de 08.04.2009. Disponível em: https://www.confaz.fazenda.gov.br/legislacao/ajustes/2009/AJ_002_09. Acesso em: jan. 2026.
MARTIN, R. C. 2019. Arquitetura limpa: o guia do artesão para estrutura e design de software. Rio de Janeiro: Alta Books.
POSTGRESQL GLOBAL DEVELOPMENT GROUP. 2024. PostgreSQL 15 Documentation. Disponível em: https://www.postgresql.org/docs/15/. Acesso em: jan. 2026.
PYTHON SOFTWARE FOUNDATION. 2024. Python 3.11 Documentation. Disponível em: https://docs.python.org/3.11/. Acesso em: jan. 2026.
Article originating from the Final Course Work of the Specialization in Software Engineering of the MBA USP/Esalq
To learn more about the course, click here and access the MBX Academy platform