# Backend Module structure

### Audit module files structure

![](https://3140720386-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LJxF2RKg63Q700gpAQ8%2F-LMmIBrrC14Ynv0A345z%2F-LMmLGtm6eBlmTMRFI4j%2FScreenshot%20from%202018-09-19%2018-00-34.png?alt=media\&token=21c0ddcb-bf1e-479b-b725-f75fee42e2c9)

`management` - specific management commands (in our case there is only one command for updating permissions)\
`migrations` - database migrations\
`notifications` - templates for email notifications\
`purchase_order` - nested global application to keep shared across the countries information about the auditor firm\
`serializers`- rest framework serializers\
&#x20;   \- `auditor.py` - serializers for auditor firm, staff members, purchase orders\
&#x20;   \- `engagement.py` - engagement related serializers (Audits, SpotChecks, Attachments, etc)\
&#x20;   \- `export` - everything that is related to CSV& PDF exports\
&#x20;   \- `mixins.py` - specific serializers mixins\
&#x20;   \- `risks.py` - Risks serializers (mainly used in MicroAssessment Questionnaire)\
\- `templates` - templates to be used in various exports (visit letter & activities PDF export)\
\- `tests` - tests for models, views, serializers, transitions flow\
\- `transitions` - everything that is related to fsm transitions\
&#x20;   \- `conditions.py` - custom checks for transitions (For example in case of submitting report we need to be assured that report attachments exists\
&#x20;   \- `serializers.py` - transitions serializers to validate their input) arguments (see more in [permissions framework section](https://razortheory.gitbook.io/third-party-monitoring-module-documentation/technical-documentation/permissions-framework))\
\- `admin.py` - admin site definitions for models\
\- `apps.py` - python app configuration\
\- `conditions.py` - permissions conditions. see more details [here](https://razortheory.gitbook.io/third-party-monitoring-module-documentation/technical-documentation/permissions-framework)\
\- `exports.py` - csv renderers\
\- `filters.py` - rest framework views filters\
\- `metadata.py` - base metadata class to be used in viewsets. more in [API Metadata section](https://razortheory.gitbook.io/third-party-monitoring-module-documentation/technical-documentation/api-metadata)\
\- `models.py` -  country-related audit models\
\- `signals.py` - app signals. custom logic for user deletion; sending notifications in case of assigning action points\
\- `urls.py` - app urls\
\- `views.py` - just set of views to work with models

### audit.purchase\_order app

![](https://3140720386-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LJxF2RKg63Q700gpAQ8%2F-LMmIBrrC14Ynv0A345z%2F-LMmLcBQhl1z9plkg7ZM%2FScreenshot%20from%202018-09-19%2018-02-08.png?alt=media\&token=d07da9cd-49c7-4f0f-adc0-1261bf32e5e6)

To store the global data that is related to Auditor Portal, nested application named `purchase_order` was implemented.\
Views and serializers are still located in the parent application to keep the consistant place for all module logic.

The App consists of the following parts:\
\- `migrations` - database migrations\
\- `tests` - unit tests\
\- `admin.py` - admin site config\
\- `apps.py` - python app config\
\- `models.py` - partner with their staff members\
\- `synchronizer.py` - VISION partner synchronizer\
\- `tasks.py` - periodic tasks, which are responsible for keeping the  partners synced with the VISION<br>
