Jump to content

Will a PHP / MySql combo be right for me?


Osteele

Recommended Posts

Hello all!

 

If I have posted in the wrong section, I apologise in advance.

 

I have a recurring task that takes place on the first of each month. Let me re-phrase that. I can send that batch file down to the bank anytime I please. Everyday, and at any time, and with varying frequency. We use an online payment server, so it's just like swiping a credit card on a merchant POS terminal.

 

Basically, I have to prepare a batch file that contains monthly payment info. The file itself is a .TXT file.

 

So, obviously there will be some form of data export taking place. By the way, the bank was nice enough to provide me with the file spec (record types and lenghts)

 

The bank refers to them as Record Type A (7 fields), G (31 fields), H (13 fields), Z (12 fields). Hope this isn't getting too confusing.

 

Most of the data in all four tables are static. The only real data that needs updating is referred to as: record count which starts at 000000001 and increments with every transaction entered. Batch ID which changes with every batch sent down eg 0010. Transaction amount. Transaction Date eg. 020107 and the clients credit number, unless his transaction had been processed in a previous batch.

 

Sorry about being so long-winded. It's a little difficult when you can't speak what you want to get across.

 

So, my question: Is this do-able and how difficult would it be for someone new to PHP / MySql.

 

One of the records called filler (which is always blank) is 1429 characters long.

 

Your suggestions and assistance would be appreciated immensely!

 

Thank you

Link to comment
https://forums.phpfreaks.com/topic/36833-will-a-php-mysql-combo-be-right-for-me/
Share on other sites

It sounds to me like you're getting a text file and creating a text file, is this correct?

If not, where is the data that you're working with (already in a database?), and what is the end result?

 

Believe it or not! As sophisticated as our banking systems are, our guys expect us to prepare and send down a text file that looks similar to this. From scratch, I might add. And no, we don't have any database whatsoever.

 

The data that we are working with is obtained from our clients. Their info is first stored on a sheet of paper.

 

A000000001ORIGINATOR000100506781510                

G000000002ORIGINATOR00015550000012076030805000453091111111101000    R

H000000003ORIGINATOR00010000000001207600000001000000000000000000000010000000000000000111111

Z000000004ORIGINATOR000100000000012076000000010000000000000000000000100000000000000

No... I mean I don't see your question. You tell us all about a file spec then just ask is it do-able? We need more detail.

 

I guess my question would be: Will I be able to enter the data into a database and somehow export all that data into a format that my bank will accept. How much of an undertaking will this turn out to be?

Are you creating a system where you enter the on-paper information into a database, then generate the output that you need?

 

I would love to skip the whole paper thing all together. So redundant. You have no idea what it's like to manually prepare that text file every time we have to send a payment down to the bank. I end up with a bunch of little files (sometimes a dozen transactions a day). Then what happens is that all those little files become a recurring transaction the following month. Don't know if I'm explaining myself properly.

Absolutely. As long as you design your database properly, you can turn the information into whatever you want.

 

Seeing as there are so few fields that are actually being written to, I would have to focus more on how fields within a table get incremented / updated. I have it all figured out on paper, and in my head. Now is where the tough stuff begins.

 

I wish I had more time to spend learning PHP / MYSQL. It seems so fascinating. Not to mention how it could make my life so much easier.

 

By the way, it's amazing how quickly you fellows were willing to provide your expertise. I am very thankful.

It's difficult to provide additional suggestions without knowing more. If you have time, post an abstract version of the business rules and you may get better feedback. For example, I'm not entirely sure that you need to use a database. I don't know how much data is involved, how much you're using at one time, or how long you plan to keep it around.

It's difficult to provide additional suggestions without knowing more. If you have time, post an abstract version of the business rules and you may get better feedback. For example, I'm not entirely sure that you need to use a database. I don't know how much data is involved, how much you're using at one time, or how long you plan to keep it around.

 

I say database, because I had assumed that the recurring transactions would have to be kept somewhere.

In any case, we definitely need a place to store client details. Some info can be extracted for later use in batch.

 

Let's see if I can map out our process in bullet form in as simple terms as possible.

 

1 - Client subscribes - provides payment info (credit card)

2 - Payment amount may be pro-rated depending on day of month

3 - For example 10 new subscribers, 10 payments to be sent down to bank

4 - Bank must do some form of validation of file.

5 - I log on to bank site where I can view reports of what has been sent. Always check the rejection report.

 

What else can I provide.

The data that we are working with is obtained from our clients. Their info is first stored on a sheet of paper.

 

To clarify, the clients are not subscribing on-line, but by mail (thus, the paper format), correct? If so, are you entering all of this data by hand at the moment?

The data that we are working with is obtained from our clients. Their info is first stored on a sheet of paper.

 

To clarify, the clients are not subscribing on-line, but by mail (thus, the paper format), correct? If so, are you entering all of this data by hand at the moment?

 

Client calls. We sign him/her while on the phone. For now, we are entering their client / payment info during that conversation. DIrectly on to a sheet of paper called Client Contact Sheet.

The data that we are working with is obtained from our clients. Their info is first stored on a sheet of paper.

 

To clarify, the clients are not subscribing on-line, but by mail (thus, the paper format), correct? If so, are you entering all of this data by hand at the moment?

 

We will usually wait for the end of day to manually enter batch info into that text file (a portion of which I pasted into an earlier message). Then off it goes. The name of the text file is always the same. By the way, if we were to enter a single space or character that would cause the record to exceed its expected length, the file will be rejected.

 

It's totally ridiculous.

Aha. Yes, it would be nice to have an interface for this. PHP and MySQL would certainly be a good solution; however, make sure they meet whatever security requirements you have. You'll also need to bring Apache into the picture, where you can use SSL.

Aha. Yes, it would be nice to have an interface for this. PHP and MySQL would certainly be a good solution; however, make sure they meet whatever security requirements you have. You'll also need to bring Apache into the picture, where you can use SSL.

 

Nice little project.. Maybe I can master PHP/MySQL before MArch 01, 2007. Because manually entering all that info is so "Stone Age"

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.