byrokrat / autogiro Goto Github PK

Use a Nodes interface in the base namespace similarl to Intervals.

Acts as a catalogue of nodes as well as preventing simple misspelling error..

In mandate responses, mandate reqords (tc 73) includes an id and an account field. These are not mandatory, and will be 0 filled for certain info and status codes (for example when a mandate has been revoked). Needs to be fixed in parser or validator...

Here is an example. Fake bg. Payer number 1.

012018032299000050501055AG-MEDAVI                                               
73005050105500000000000000010000000000000000000000000000     033320180322       
092018032299000000001                                                           

In a parent-child node relationship the child is currently not aware of it's name. Adding name as a member of Node whould make printing the element name when we generate XML a simple thing, and generally makes sense.

This would however mean that name must be known at node creation in parser. A problem when the same node type is used multiple times in the same record. For example INT6 is used repeatedly for record counts in closing nodes. This issue needs to be resolved...

Possible as a new project. But for now a simple script would do..

Filename or stdin will do just fine..

The tree structure needs to be solid. Some issues and thoughts...

• Naming. Should all request nodes start with Request or end with RequestNode? Eg RequestOpeningRecordNode or OpeningRecordRequestNode. (Of course the same goes for response nodes.)

• Tree. Is the tree to deep? Do we really need Tree/Record/Response? Is not Tree/Response or Tree/Record enough...

• There is an OpeningRecordNode but it is not generic (not used in both request and response layouts). Putting it in the Tree/Record namespace make it look generic. If there are functionality here that is important lets make it an abstract class.

• Document all tree changes in UPDATING.md.

Conversion needed in parser. Fails with my local testset. See previous work in tmp-transitional-ag.

Use a Visitor instead. The simple readme example can use an anonymous class...

Approve a recieved digital mandate.

Response layouts typically contains a closing record that specifies the number of different records in the file (and the summed amounts for transactions). These counts can be validated using a visitor.

A generic CountingVisitor could count all node types and validate the count using a generic Closing record node. The type of node a count refers to could be specified at parse time.

Monetary amounts could possible be validated in the same manner.

Edit: There is now a generic closing record universaly applied.

Possibly fix in PrintingVisitor

Presently we use a PHP interface. This does not feel optimal. Some other datasource would be better. A simple json collection?

Also there seems to be two ways of noting messages in Messages.php. A blast from the past? Make sure all messages are stored using the same semantics.

I've been looking for a way to parse BGC-files and found this package. However none of the test files work. When trying the new format this is the error I get

[byrokrat\autogiro\Exception\ContentException] Tree invalid due to the following issues:
Parser: Syntax error, expecting '01', REQ_OPENING_RECORD, REQ_MANDATE_LAYOUT, REQ_PAYMENT_LAYOUT, REQ_AMENDMENT_LAYOUT, REQUEST_FILE, '01', RESP_MANDATE_OPENING_OLD_RECORD, '01', GENERIC_OPENING_RECORD, RESP_MANDATE_FILE, FILE on line 1

If I remove the following from the test file:

[---+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8

I get below error instead

[byrokrat\autogiro\Exception\ContentException] Tree invalid due to the following issues:
Parser: Syntax error, expecting ALPHA-NUMERIC on line 1

Steps to reproduce

1. Download zip

2. Add a testfile

<?php
require_once('vendor/autoload.php');
$factory = new \byrokrat\autogiro\Parser\ParserFactory;
$parser = $factory->createParser();
$fileNode = $parser->parse(file_get_contents('tests/ny_layout/autogiro_exempelfil_bet-spec-o-tk_sv.txt'));

Adds a new paper based mandate

This issue tracks the current layout implementation status.

Parsing and writing request layouts

• Writing mandate requests
• Parsing mandate requests
• Writing payment requests
• Parsing payment requests
• Writing amendment requests
• Parsing amendment requests

Parsing response layouts

• Payment responses
• Mandate responses
• Rejected payment responses
• Amendment responses
• Digital mandate responses
• Payment registry extract responses
• Mandate registry extract responses
• Payment responses in BGMAX format (will not be supported, but should generate an informative error message..)

If there is only one rule mapping a transaction code in Grammar the cut operator can probably be used after the TC to speed up parsing.

No idea to implement before grammar is more or less complete as this can lead buggy behaviour when new rules are added...

Fix deprecated method calls..