Re: Adding a required field during Checkout that Shows on the Invoice
Kobra,
The one you suggested doesn't populate on the packing slip or invoice.
The data I would like to input is text.
Re: Adding a required field during Checkout that Shows on the Invoice
Quote:
The one you suggested doesn't populate on the packing slip or invoice.
It stores it with some variable to the DB
One would have to add the variable to the invoice etc
Re: Adding a required field during Checkout that Shows on the Invoice
Kobra,
That sounds great. It sounds like it is just a matter of (for text) duplicating that add on, modifying the options then adding it to the invoice.
Thank you again for the start. It is appreciated.
Re: Adding a required field during Checkout that Shows on the Invoice
To Rabbcon and kobra, appreciate your thoughts. And I especially agree with Rabbcon regarding un-answered posts. The dilemma here is that 80% of posted questions are usually simply install errors or RTFM (read the $@#% manual) problems so many are duplicated and thus ignored. As a developer myself I certainly do not have time to be answering the simple questions.
As a reasonably experienced user of ZC I try and avoid any third-party modules that involve database modification wherever possible (so kobra I wasn't looking for a module!) because I wish to keep the code as tight as possible.
All I want to do is append field data to an existing database variable which is already used in the invoice display. I would have thought this is far simpler than using third-party modules and modifying the database.
But I just can't see how the final page variables (as mentioned assume they are in some sort of an array) get written to the database. As you would know from the code most pages are includes+includes+includes which makes reverse engineering very tedious and difficult, so all I was looking for was insight as to where (ie which files) this is happening.
So my point remains the same - as a developer the biggest problem with ZC is that serious help/support is just too hit-and-miss.
----------------------------------------------------------------
Why "not" to use modules.
Of course I use the modules, but the more I use them the less I like the implementation.
My biggest problem is that, I (like many others I suspect) have been caught with these modules not working/no longer supported. The scary part here was that one module (which calculated postage rates) did not stop working - it just stopped "calculating" properly. So I did not notice this until several months later. It was only "after" finding out this information and having a rant (another...!) with the developer that the module was removed from the downloads list, where it was still appearing as a totally valid and updated module!
And with the current "optional" implementation of the module manager (where some require it and some don't) the module management side is only getting messier rather than simpler. EG what happens if the developer coding the Module Manager decides to abandon ship?
Modules are a great idea, but for me they need to start getting a little bit more refined as to how they are managed.
------------------------------------------------------------
At the end of the day for me it is about money. I'm at the point where I would *like* to:
1. pay to be on a developer forum where:
a. you wouldn't get silly posts
b. you would be assured of a response
I expect that being on this forum would sort out many of the recent data-mining issues with ZC and rampant indexing spiders without me having to do hours of research.......
2. pay a registration fee with module programmers who would then "push" me updated information/patches.
So whilst I do think it is great OS software (which was why I used it in the first place) I'm a developer who doesn't *want* to be continually checking that the code/modules are working so I am recommending to my client that she should now begin looking at commercial software.
---------------------------------------------
When I was asking for recommendations obviously others have taken this path before, so I was hoping other users could give some insight as to which packages import the raw ZC data (ie from the database) the best.
I would have thought the attributes would be the biggest head-ache?
Anyway, thanks again for responding :smile: Adrian