atol-online/ROADMAP.md

# Roadmap

Здесь перечислены реализованные функции и находящиеся в разработке.

Порядок их упоминания здесь может не совпадать с порядком реализации.

Эталонная реализация подразумевает полную поддержку всех методов API и обеих схем документов:
* [Документы прихода, возврата прихода, расхода, возврата расхода](https://online.atol.ru/possystem/v4/schema/sell)
* [Документы коррекции прихода, коррекции расхода](https://online.atol.ru/possystem/v4/schema/correction)

## Общий функционал библиотеки

- [x] Переключение настроек доступа к ККТ при переключении тестового режима
- [x] Тесты для класса налоговой ставки (+ массив)
- [ ] Тесты для класса оплаты (+ массив)
- [x] Тесты для класса предмета расчёта (+ массив)
- [x] Тесты для класса клиента
- [x] Тесты для класса компании
- [ ] Тесты для класса данных коррекций
- [ ] Тесты для класса документа
- [ ] Тесты для класса ответа ККТ
- [ ] Тесты для регистрации документа прихода
- [ ] Тесты для регистрации документа возврата прихода
- [ ] Тесты для регистрации документа коррекции прихода
- [ ] Тесты для регистрации документа расхода
- [ ] Тесты для регистрации документа возврата расхода
- [ ] Тесты для регистрации документа коррекции расхода
- [ ] Вообще все расчёты вообще везде должны быть строго в копейках. Рубли (дроби) должны быть только в JSON-представлениях

## Поддержка методов API (регистрация документов)

- [x] приход
- [x] расход
- [x] возврат прихода
- [x] возврат расхода
- [x] коррекция прихода
- [x] коррекция расхода
- [x] проверка статуса документа

## Документы прихода, возврата прихода, расхода, возврата расхода

- [x] Пoддержка `receipt.client` (обязательный)
- [x] Пoддержка `receipt.company` (обязательный)
- [x] Пoддержка `receipt.items` (обязательный)
- [x] Пoддержка `receipt.total` (обязательный)
- [x] Пoддержка `receipt.payments` (обязательный)
- [x] Пoддержка `receipt.vats`
- [ ] Пoддержка `receipt.additional_check_props`
- [x] Пoддержка `receipt.cashier`
- [ ] Пoддержка `receipt.additional_user_props`
- [ ] Пoддержка `receipt.agent_info`
- [ ] Пoддержка `receipt.supplier_info`
- [ ] Пoддержка `receipt.items.agent_info`
- [ ] Пoддержка `receipt.items.supplier_info`
- [ ] Пoддержка `receipt.items.nomenclature_code`
- [ ] Пoддержка `receipt.items.excise`
- [ ] Пoддержка `receipt.items.country_code`
- [ ] Пoддержка `receipt.items.declaration_number`

## Документы коррекции прихода, коррекции расхода

- [x] Пoддержка `correction.company` (обязательный)
- [x] Пoддержка `correction.vats` (обязательный)
- [x] Пoддержка `correction.correction_info` (обязательный)
- [x] Пoддержка `correction.cashier`

## Не будут реализовываться

### Валидация генерируемых документов согласно актуальной схемы API

- Валидатор схемы для документов прихода, возврата прихода, расхода, возврата расхода
- Валидатор схемы для документов коррекции прихода, коррекции расхода

1. Отказ обусловлен скоростью выполнения. 
Базовая реализация, которая была начата, подразумевала синглтон, который кешировал однажды полученную схему.
Практика показала, что этот единичный запрос может существенно тормозить работу сервера и в течение долгого времени
не отдавать ответ клиенту.

2. Такая валидация подходит в том случае, если бы при разработке использовалась концепция IoC.
До версии пакета 2.0.0 таких серьёзных имзенений не планируется.