topic Re: Changing the Revision Date in AC 18 in Project data & BIM

Changing the Revision Date in AC 18

Anonymous — Fri, 19 May 2023 22:07:18 GMT

I must be missing something using the Revision Manager in AC 18...

When an issue is currently open, the issue date is automatically set to "work in progress". We cannot set the date manually.

When an issue is closed, the issue date is automatically set to the date the "close issue" button was clicked. We cannot set the date manually.

Anyone know how to manually set the date?

thanks

Re: Changing the Revision Date in AC 18

Laszlo Nagy — Mon, 11 Aug 2014 22:34:05 GMT

I think it is not possible to manually set a date.
You can probably change your system date, close the issue, then set the system date back to normal.
I don't know, you might have to restart ArchiCAD for it to read the new system date, but maybe not, I haven't tried it.

Re: Changing the Revision Date in AC 18

Anonymous — Mon, 11 Aug 2014 22:42:47 GMT

If true, then that is an enormous design flaw.

For example: if the team is working toward issuing a set next wednesday they wouldn't actually be able to close the issue and publish EXCEPT ON THAT EXACT DAY?!

Huge fail. Someone please tell me this isn't true.

Re: Changing the Revision Date in AC 18

Eduardo Rolon — Tue, 12 Aug 2014 00:31:22 GMT

The "accepted" trick is to create a Custom Field for the Date and use the "hardwired" one as a baseline.

Re: Changing the Revision Date in AC 18

Anonymous — Tue, 12 Aug 2014 22:36:13 GMT

Thanks. I'll give that a try.

Re: Changing the Revision Date in AC 18

Marton Kiss — Mon, 18 Aug 2014 12:42:23 GMT

Thanks Eric for bringing this up. I forwarded this to our design team for consideration.

Marton

Re: Changing the Revision Date in AC 18

__archiben — Thu, 21 Aug 2014 23:12:30 GMT

Eric wrote:
If true, then that is an enormous design flaw.

For example: if the team is working toward issuing a set next wednesday they wouldn't actually be able to close the issue and publish EXCEPT ON THAT EXACT DAY?!

Huge fail. Someone please tell me this isn't true.

I hear you - massive fail. I battled for hours last night trying to bend revision manager to my requirements. Utter failure and a wasted five hours.

I need to a bring a big project through from 17 which has manual revisions already noted on the layouts: I thought it would be easy to create the historic revisions to be able to take advantage of the revisioning system going forward. Scratch that idea.

I would also like for my revisions to be to letters. Too much to ask? It appears so: How can I make my Revision ID a letter that clocks up for each layout automatically????? A custom field in the scheme (WTF is that all about anyway?) like the date work-around above does not work in this case because each layout needs to clock up one letter on an individual basis....

Re: Changing the Revision Date in AC 18

__archiben — Fri, 22 Aug 2014 00:01:14 GMT

And don't get me started about about autotext in the publisher...

Firstly, who thought it was a good idea to exclude the project number, (or even the project name if you like long file names!) from the list of available autotext options? Project names/numbers are as critical to document management in a file system as dates, revisions and status in any industry not just architecture.

And then there is the age-old 80% complete publisher feature that makes a nonsense of the whole automation process: If you add a new layout (or any publishing item), to a publishing set after you have set up custom naming rules / print options / export file types it still just comes through as a plain-old vanilla, built-in automatic conventions.

This is a HUGE issue right the way through the project navigator which makes a mockery of trying to automate anything in ArchiCAD: cloned viewpoints with custom view settings are ignored if a new Viewpoint is created when different settings are active; cloned layouts or even the entire cloned layout book in publisher sets default to standard print settings, file types, etc if a new layout is created after the publishing set its created and customised... want to print a reduced A3 set of your documents? Great except that all of the layouts created after the publisher set is customised to 'Fit to page' in the printer still print as 8 tiled sheets... want to quickly publish a DWG batch to send to a collaborator? Of course you can, except for all those PDF files you created by accident because any newly item item to a "Save files" publisher set automatically default to PDF... Want the custom naming conventions of published>saved files in AC18 to be applied to any new layout added to that publisher set? Of course you do, except that it doesn't.

Want to know what's worse than manually managing the publishing and file saving requirements of a complex and large system? Managing a half-automatic/half-manual complex system, that's what. I've lost count of the amount of times I've recreated entire view subsets, and complete publisher sets because I've lost track of what's working automatically and what's new and requires manually adjusting. I've lost count of the times I've printed a reduced A3 set and had a batch of tiled A1 drawings (8xA3 sheets with mostly blank and cropped information) appear half way through somewhere.

Here is the really easy principle to fix the publisher and actually bring true automation to ArchiCAD's file management - which is especially critical with the launch of Revision Management. Ready? A child item inherits the rules of its enclosing parent unless it itself has been manually modified.

How difficult can it be?

Re: Changing the Revision Date in AC 18

Gergely Hari — Mon, 25 Aug 2014 10:20:00 GMT

About Issue Date:
this is precisely why we included the custom fields in the Issue / Change, so you can add any data to them, and list that data both in the Revision History / in the project indexes / autotexts.

All dates behave the same way as any created/modified date in any file system: they are maintained automatically, based on when things actually happen to it; but if you need other dates for identification purposes, you can add them as metadata to the file / just include them in the filename.

Same here, if you're content with the system date, because you work on projects small enough that you actually close the issue on the day you wish to appear on the Layout, then use the system date. If you need to identify a different date, add that date manually to the Issue.

About publisher renaming:
- I agree the list could be more extensive, but right now the set is limited to those fields that can actually be different Layout-by-Layout. When batch-renaming all Layouts in a publisher set, it isn't that hard to include the project ID manually in the scheme; you only have to do it once - not nearly as problematic as renaming the Layouts one-by-one. So data that is common to all layouts was not included in the possible autotext list, only data that is different per layout.

- New items not inheriting the naming scheme: This might be a bug; it is expected to behave the same way as with file types: If all are the same in one folder, the new one inherits that, if they are different, it inherits a default. I will check and log it.

About Revision IDs: see my other reply here.

Re: Changing the Revision Date in AC 18

Laszlo Nagy — Mon, 25 Aug 2014 13:51:49 GMT

This clip may be helpful about the Publisher Set renaming as it shows that you can type normal text as part of the code for those custom names:

https://www.youtube.com/watch?v=2bKxs-PIpH4

Re: Changing the Revision Date in AC 18

__archiben — Mon, 25 Aug 2014 21:40:11 GMT

Gergely wrote:
- New items not inheriting the naming scheme: This might be a bug; it is expected to behave the same way as with file types: If all are the same in one folder, the new one inherits that, if they are different, it inherits a default. I will check and log it.

If you could look at this I would really appreciate it - it's been bugging me for as long as the navigator has been around and I honestly thought that it was by design rather than a bug...! just to be sure we're talking the same language:

if i set a series of parameters on the top parent of the navigator tree, all new items that get added to the tree will inherit those settings rather than some system default or default settings that exist in the viewpoint at the time? by extension, if i set a series of parameters on a folder in the view map or publisher, any item that gets added automatically to that folder inherits the settings of the folder rather than the default setting of the navigator tree?

please tell me it's a bug that you're going to nail in the next hotfix and i will be very happy!

~/b

Re: Changing the Revision Date in AC 18

__archiben — Mon, 25 Aug 2014 21:46:54 GMT

laszlonagy wrote:
This clip may be helpful about the Publisher Set renaming as it shows that you can type normal text as part of the code for those custom names:

https://www.youtube.com/watch?v=2bKxs-PIpH4

my issue is with the automation of things lazslo - publishing automation in particular has the potential to save hours and hours of mundane work yet is only partly working so in fact the time saved in what does work well is spent checking things to make sure all of the published items did in fact get created as intended. i exaggerate: it does save time of course but it could save much more!

when joe user opens a new project from a template file and duly fills in the known Project Information, shouldn't that get propagated to the areas where it's needed throughout the file? if the job number is already there let's use it wisely!

i've already in fact used normal text in my naming for something that is constant across every single project it's in: the word " Rev "

<CURRENTISSUECUSTOMPAR1>_<SourceID> Rev <CURRENTREVISIONID>-<SourceItemName>

at the moment i'm using '<CURRENTISSUECUSTOMPAR1>' as the project number which requires it being typed in manually whenever a new issue is opened. (and perhaps in the future the '...CUSTOMPAR1' part can be replaced as far as me the user is concerned with actual name that i define for it?). at least this has the potential to ensure that the project number makes it to the file name because it presents a dialogue to be filled in for each and every file using it as a template, (and people love filling in boxes, right?! ). globally changing the published items naming rules relies on remembering a manual intervention in each and every project using the template.

~/b

Re: Changing the Revision Date in AC 18

Gerry Leonor — Thu, 06 Nov 2014 04:35:39 GMT

+1 on changing the System Date/Time to match the previously issued dates. i changed the system date/time as needed, then closed the issue, then remembered to change it back. fortunately for me, i only had to deal with 1 previously published issue. but that certainly worked for me.

hoping a proper fix is applied soon.

Re: Changing the Revision Date in AC 18

Paul King — Mon, 18 Apr 2016 23:58:05 GMT

Gergely wrote:
About Issue Date:
this is precisely why we included the custom fields in the Issue / Change, so you can add any data to them, and list that data both in the Revision History / in the project indexes / autotexts.

About Revision IDs: see my other reply here.

If a need to edit any one date triggers a requirement to manually add/edit ALL dates, this entirely defeats the purpose of automation.

We need the ability to individually override past dates, revision ID, descriptions etc, e.g when a user mistake is found from two issues ago, but for any new information to be automatically added and correct

Re: Changing the Revision Date in AC 18

__archiben — Sun, 08 May 2016 20:33:27 GMT

Create a custom Issue Scheme for any autotext you want to control and appear by-sheet (rather than by-project).

Re: Changing the Revision Date in AC 18

Paul King — Sun, 08 May 2016 22:44:24 GMT

~/archiben wrote:
Create a custom Issue Scheme for any autotext you want to control and appear by-sheet (rather than by-project).

Thanks Ben. Would doing this once a project has already been issued several times already not then trigger the problem I was hoping to avoid though? (i.e. the need to go back and manually populate past revision dates, and manually populate new ones thereafter?

I am thinking in particular of the resulting drawing register document - the revision date column will need to be populated by either system issue date or manual custom issue date - not sure of any way to tell ArchiCAD to automatically know when to switch from one to another and back again as it goes down the page